Nate
> On Jan 9, 2018, at 12:12 AM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: > > >> 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. 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) substitute. > Finally, is anyone actually using this type? In the standard library, we have this Mirror initializer: https://developer.apple.com/documentation/swift/mirror/1540408-init. 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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
