<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 8, 2018, at 10:12 PM, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 8, 2018, at 4:29 PM, Ben Cohen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div class="">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 class=""><br class="">Instead, it’s just an immutable collection of key-value pairs you can create _from_ a literal.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Wow. This is really gross, I didn’t know it existed :-)</div><div class=""><br class=""></div><div class="">Random question for you. DictionaryLiteral has this doc comment:</div><div class=""><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">/// You initialize a `DictionaryLiteral` instance using a Swift dictionary</div></div><div class=""><div class="">/// literal. Besides maintaining the order of the original dictionary literal,</div></div><div class=""><div class="">/// `DictionaryLiteral` also allows duplicates keys. For example:</div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">why is maintaining duplicate keys a feature?</div><div class=""><br class=""></div></div></div></div></blockquote><div><br class=""></div><div>Allowing duplicate keys can be useful depending on the use case. Though you could argue they shouldn’t be called keys then…</div><div><br class=""></div><div>This type can be described as “just an ordered immutable list of pairs that you can declare using the `[:]` syntax because that looks nicer than `[(,)]`” . Allowing duplicate keys, and preserving declaration order, is just what it does.</div><div><br class=""></div><div>One thought I had was we could replace it with conditional conformance by making `Array: ExpressibleByDictionaryLiteral where Element = (Key,Value)`. But we can’t do that quite yet, because I think it needs [parameterized extensions](<a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#parameterized-extensions" class="">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#parameterized-extensions</a>). Also that might be confusing too ("huh, I can create an array from a dictionary literal???”).</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">It also has this one:</div><div class=""><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">/// Some operations that are efficient on a dictionary are slower when using</div></div><div class=""><div class="">/// `DictionaryLiteral`. In particular, to find the value matching a key, you</div></div><div class=""><div class="">/// must search through every element of the collection. The call to</div></div><div class=""><div class="">/// `index(where:)` in the following example must traverse the whole</div></div><div class=""><div class="">/// collection to find the element that matches the predicate:</div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">Since it is immutable, why not sort the keys in the initializer, allowing an efficient binary search to look up values?</div><div class=""><br class=""></div></div></div></div></blockquote><div><br class=""></div><div>Because it’s currently in user-declared order, like an array. I don’t think we could change that without breaking any code that uses it for what it does today. Here’s an example in the wild that is reliant on preserving order:</div><div><a href="https://github.com/apple/swift/blob/master/benchmark/single-source/RomanNumbers.swift#L28" class="">https://github.com/apple/swift/blob/master/benchmark/single-source/RomanNumbers.swift#L28</a>.</div><div><br class=""></div><div>We will hopefully add a value-type sorted dictionary too, at some point, which would cover the sorted literal use case.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">I’m canvassing for opinions on what it ought to be called. Some suggestions so far:<br class=""><br class=""> - `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 class=""> - `KeyValueCollection`: Problematic because key-value comes up in a totally different context in Cocoa.<br class=""> - `PairCollection`: “Pair” is kinda nondescript.<br class=""> - Do nothing. It’s not so bad.<br class=""><br class="">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 class=""></div></div></blockquote></div><br class=""><div class="">I’m not familiar with this type at all, so I apologize for the dumb question but… why was this added in the first place? If it is the wrong thing, why not just deprecate it in Swift 5 and remove it in a future release? </div></div></div></blockquote><div><br class=""></div><div>Given it’s going to be in the ABI regardless, and has at least some marginal utility, if we can find a more sensible name for it is there any strong motivation to deprecate it?</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">That avoids it being an ABI concern, because we could make it be force inlined into any client code.</div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>"we could make it be force inlined into any client code” isn’t a feature we currently plan on having unfortunately. Also this is a type rather than just a method, so we’d need a feature to always emit the symbol into the client too.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Finally, is anyone actually using this type?</div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>IMO that isn’t a question we should be asking any more except in cases where an existing implementation is causing active harm. Which, confusing name aside, this type isn’t (aside from API sprawl I guess).</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">-Chris</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></body></html>