[swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Xiaodi Wu]

Thank you for the clarification. It occurred to me in the shower that this
might be the case, and that I was entirely mistaken as to what we were
talking about.

Yes, then, I wholeheartedly agree on this point. Out of curiosity, why are
there source stability issues to 'typealias DictionaryLiteral<Key, Value> =
[(Key, Value)]'?
On Mon, Jan 8, 2018 at 23:25 Nate Cook <natecook at apple.com> wrote:

>
> On Jan 8, 2018, at 9:07 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> While there’s nothing specifically to do with a dictionary, it is a
> literal in at least one essential respect. Like other literals, it doesn’t
> have a type, but values that are expressed by them do acquire a type given
> the context.
>
>
> This confusion is why we really need to rename this—there are two separate
> things:
>
> 1) *Dictionary literals.* These are written as comma-separated key-value
> pairs, with each key-value pair separated by a colon—[a: b, c: d, e: f].
> Most users of Swift have probably only ever used these to create instances
> of the Dictionary type, but any type that conforms to
> ExpressibleByDictionaryLiteral can be expressed using one. Crucially, like
> integer literals that can express an `Int` value, a `UInt8` value, or a
> value of any other integer or floating-point type, dictionary literals have *no
> concrete type* until they’re evaluated in context.
>
> 2) *The `DictionaryLiteral` type.* This is a generic type that conforms
> to ExpressibleByDictionaryLiteral, but is otherwise an unremarkable
> collection with `(Key, Value)` elements. You can see its declaration here:
> https://github.com/apple/swift/blob/master/stdlib/public/core/Mirror.swift#L855.
> Despite the name, `DictionaryLiteral` is not a literal—it’s a concrete type
> and can’t be used to express dictionaries or other types that conform to
> `ExpressibleByDictionaryLiteral`.
>
> It’s #2 that we’re talking about renaming, and while I think both parts of
> the name (“Dictionary” and “Literal”) are inaccurate, “Literal” is more
> problematic because of the confusion it causes with lower-case literals.
>
> Nate
>
> Yes, it's not a dictionary, but neither is an integer literal an integer
> (or even necessarily an integer you can create from such a literal: it can
> be a floating-point value you create from that literal), etc. Would
> "ordered collection of key-value pairs" be more "correct"? By the same
> token, we ought to be renaming integer literals "ordered collection of
> digits without interposed decimal point."
>
> But essentially every user will have encountered this spelling in the
> context of dictionaries: in other words, its name has a good basis in
> reality because it is the (only) literal spelling that can be used to
> create a dictionary, and when you say "hey, that spelling you use for a
> literal to instantiate a dictionary in Swift," everyone will know what
> you're talking about.
>
> No, I think we ought to do nothing. It's not only "not bad," but as far as
> I can tell quite superior to the alternatives in essentially every respect.
> In the alternative, maybe "KeyValueLiteral" or something of that sort, but
> I still would consider that to be strictly inferior to "DictionaryLiteral".
>
>
> On Mon, Jan 8, 2018 at 20:24 Nate Cook via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> > On Jan 8, 2018, at 6: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.
>> >
>> > 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.
>>
>> Agreed so far, and I'd like to add CollectionOfPairs to the list.
>>
>> Some more fun facts about this type:
>> - Besides Dictionary, it's the only other type in the standard library
>> that is expressible by a dictionary literal
>> - Unlike Dictionary, it *does* maintain the order of its pairs
>> - Unlike Dictionary (part 2), it *doesn't* require the first element of
>> the pairs to be Hashable
>>
>> Nate
>>
>> > 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.
>> >
>> > Any further thoughts welcome.
>> >
>> >
>> >
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180109/43536301/attachment.html>