> On Jan 9, 2018, at 12:12 AM, Chris Lattner via swift-evolution 
> <> wrote:
>> On Jan 8, 2018, at 4:29 PM, Ben Cohen via swift-evolution 
>> <> 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.

According to now-gone doc comments, it's intended to be used when providing the 
children for a custom mirror (that's the only API I know of that uses the 
type). The order of elements there is important, but given how scarcely used 
the type is, an array of tuples might be a reasonable (though source-breaking) 

> Finally, is anyone actually using this type?

In the standard library, we have this Mirror initializer: If anyone 
is customizing their type's mirror, it's a good bet that they're calling that 
init and passing a literal that would break if the argument changed to an 
array. The translation should be mechanical, so maybe it could be a migrator 
fix? (I don't know enough about how that works to know.)

> -Chris
> _______________________________________________
> swift-evolution mailing list
swift-evolution mailing list

Reply via email to