[swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Chris Lattner]

> On Jan 8, 2018, at 4:29 PM, Ben Cohen via swift-evolution <swift-evolution at swift.org> wrote:
> 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. 
> 
> Instead, it’s just an immutable collection of key-value pairs you can create _from_ a literal.

Wow.  This is really gross, I didn’t know it existed :-)

Random question for you.  DictionaryLiteral has this doc comment:

/// You initialize a `DictionaryLiteral` instance using a Swift dictionary
/// literal. Besides maintaining the order of the original dictionary literal,
/// `DictionaryLiteral` also allows duplicates keys. For example:

why is maintaining duplicate keys a feature?


It also has this one:

/// Some operations that are efficient on a dictionary are slower when using
/// `DictionaryLiteral`. In particular, to find the value matching a key, you
/// must search through every element of the collection. The call to
/// `index(where:)` in the following example must traverse the whole
/// collection to find the element that matches the predicate:

Since it is immutable, why not sort the keys in the initializer, allowing an efficient binary search to look up values?


> I’m canvassing for opinions on what it ought to be called.  Some suggestions so far:
> 
> - `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.
> - `KeyValueCollection`: Problematic because key-value comes up in a totally different context in Cocoa.
> - `PairCollection`: “Pair” is kinda nondescript.
> - Do nothing. It’s not so bad.
> 
> 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.

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?  That avoids it being an ABI concern, because we could make it be force inlined into any client code.

Finally, is anyone actually using this type?

-Chris



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180108/75d24867/attachment.html>