> On Jan 8, 2018, at 4:29 PM, Ben Cohen via swift-evolution > <swift-evolution@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
