[swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ben Cohen]

> On Jan 9, 2018, at 11:48 AM, Chris Lattner <clattner at nondot.org> wrote:
> 
>> 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.
> 

Personally, I feel like this argument for removal as past its use-by date. It was a good reason for Swift 3, tenuous for 4 and should be ruled out for 5, since the source stability bar has been raised since. Like I said, IMO the criteria should now be “active harm”. I also don’t think searches of GitHub etc are sufficient justification, except when combined with the active-harm argument. I also don’t think the origin story of the type – whether accidental or intentional – is relevant to the decision of what to do with it now. It exists and people can legitimately use it for their own purposes independent of mirrors.

>>> 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?”
> 

The bar for removal and the bar for additions are different. I don’t buy the slippery slope argument, and surely neither would anyone else if it were used as a justification for new frivolous additions, so this seems like a non-issue to me.

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

Absent a proposal to change them to something better (and I’m not aware of one pending), the plan is they are what they are, at least the public API of Swift.Mirror. I would guess this whole area is a candidate to be overhauled significantly at some point in the post-Swift 5 future with some more fully-fledged reflection system, but there is little chance of this happening before ABI stability, and interim tinkering doesn’t seem worthwhile to me.

> -Chris