Thank you for the clarification. It occurred to me in the shower that this might be the case, and that I was entirely mistaken as to what we were talking about.<br><br>Yes, then, I wholeheartedly agree on this point. Out of curiosity, why are there source stability issues to &#39;typealias DictionaryLiteral&lt;Key, Value&gt; = [(Key, Value)]&#39;?<br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 8, 2018 at 23:25 Nate Cook &lt;<a href="mailto:natecook@apple.com">natecook@apple.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><br><div>On Jan 8, 2018, at 9:07 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">While there’s nothing specifically to do with a dictionary, it is a literal in at least one essential respect. Like other literals, it doesn’t have a type, but values that are expressed by them do acquire a type given the context.</div></div></blockquote><div><br></div></div><div dir="auto"><div>This confusion is why we really need to rename this—there are two separate things:</div><div><br></div><div>1) <i>Dictionary literals.</i> These are written as comma-separated key-value pairs, with each key-value pair separated by a colon—[a: b, c: d, e: f]. Most users of Swift have probably only ever used these to create instances of the Dictionary type, but any type that conforms to ExpressibleByDictionaryLiteral can be expressed using one. Crucially, like integer literals that can express an `Int` value, a `UInt8` value, or a value of any other integer or floating-point type, dictionary literals have <b>no concrete type</b> until they’re evaluated in context.</div><div><br></div>2) <i>The `DictionaryLiteral` type.</i> This is a generic type that conforms to ExpressibleByDictionaryLiteral, but is otherwise an unremarkable collection with `(Key, Value)` elements. You can see its declaration here: <a href="https://github.com/apple/swift/blob/master/stdlib/public/core/Mirror.swift#L855" target="_blank">https://github.com/apple/swift/blob/master/stdlib/public/core/Mirror.swift#L855</a>. Despite the name, `DictionaryLiteral` is not a literal—it’s a concrete type and can’t be used to express dictionaries or other types that conform to `ExpressibleByDictionaryLiteral`.<div><br></div><div>It’s #2 that we’re talking about renaming, and while I think both parts of the name (“Dictionary” and “Literal”) are inaccurate, “Literal” is more problematic because of the confusion it causes with lower-case literals.</div></div><div dir="auto"><div><br></div><div>Nate</div></div><div dir="auto"><div><br><blockquote type="cite"><div><div dir="ltr"><div>Yes, it&#39;s not a dictionary, but neither is an integer literal an integer (or even necessarily an integer you can create from such a literal: it can be a floating-point value you create from that literal), etc. Would &quot;ordered collection of key-value pairs&quot; be more &quot;correct&quot;? By the same token, we ought to be renaming integer literals &quot;ordered collection of digits without interposed decimal point.&quot;</div><div><br></div><div>But essentially every user will have encountered this spelling in the context of dictionaries: in other words, its name has a good basis in reality because it is the (only) literal spelling that can be used to create a dictionary, and when you say &quot;hey, that spelling you use for a literal to instantiate a dictionary in Swift,&quot; everyone will know what you&#39;re talking about. </div><div><br></div><div>No, I think we ought to do nothing. It&#39;s not only &quot;not bad,&quot; but as far as I can tell quite superior to the alternatives in essentially every respect. In the alternative, maybe &quot;KeyValueLiteral&quot; or something of that sort, but I still would consider that to be strictly inferior to &quot;DictionaryLiteral&quot;.<br><div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 8, 2018 at 20:24 Nate Cook via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
&gt; On Jan 8, 2018, at 6:29 PM, Ben Cohen via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt; There exists in the standard library a type `DictionaryLiteral` that deserves naming re-consideration before we declare ABI Stability, because it’s confusingly misnamed, being neither a Dictionary (it doesn’t provide key-based lookup of values) nor a Literal.<br>
&gt;<br>
&gt; Instead, it’s just an immutable collection of key-value pairs you can create _from_ a literal.<br>
&gt;<br>
&gt; I’m canvassing for opinions on what it ought to be called.  Some suggestions so far:<br>
&gt;<br>
&gt; - `AssociationCollection`: Following the term of art from some other languages. Slightly obscure-sounding to developers not already familiar. Also “association” and “associative” are confusingly similar, which brings back the is-this-a-dictionary problem.<br>
&gt; - `KeyValueCollection`: Problematic because key-value comes up in a totally different context in Cocoa.<br>
&gt; - `PairCollection`: “Pair” is kinda nondescript.<br>
&gt; - Do nothing. It’s not so bad.<br>
<br>
Agreed so far, and I&#39;d like to add CollectionOfPairs to the list.<br>
<br>
Some more fun facts about this type:<br>
- Besides Dictionary, it&#39;s the only other type in the standard library that is expressible by a dictionary literal<br>
- Unlike Dictionary, it *does* maintain the order of its pairs<br>
- Unlike Dictionary (part 2), it *doesn&#39;t* require the first element of the pairs to be Hashable<br>
<br>
Nate<br>
<br>
&gt; The old name can live on indefinitely via a typealias (which has no ABI consequences, so could be retired at a later date once everyone has had plenty of time to address the deprecation warnings). Removing it as not carrying its weight (and instead using `[(Key,Value)]`, which is basically what it’s a wrapper for) is probably off the table for source stability reasons.<br>
&gt;<br>
&gt; Any further thoughts welcome.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div></div></div>
</div></blockquote></div></div></blockquote></div>