[swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Chris Lattner]

> On Jan 9, 2018, at 10:23 AM, Ben Cohen <ben_cohen at apple.com> wrote:
>>> 
>>> 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?  
> 
> Given it’s going to be in the ABI regardless, and has at least some marginal utility, if we can find a more sensible name for it is there any strong motivation to deprecate it?

+1 for renaming it to something that isn’t super confusing, but +100 for removing it outright.

Rationale: if we didn’t have this functionality in the stdlib today, we would not consider adding it.  It doesn’t meet the bar we’ve set for what is in the standard library.  It only exists there by historical accident.  The Mirror API was not carefully considered.

>> Finally, is anyone actually using this type?
>> 
> 
> IMO that isn’t a question we should be asking any more except in cases where an existing implementation is causing active harm. Which, confusing name aside, this type isn’t (aside from API sprawl I guess).

It directly impacts code size for applications of swift that use the standard library as a standard library, e.g. a raspberry pi dev situation.  It is also bloat, and also takes us down a slippery slope by allowing people to say “if that weird thing is in, why can’t I add my own narrow enhancement?”


More to the point though, this seems like an implementation detail of Mirrors.  What is the plan for Mirrors + ABI stability?

-Chris