Excellent Idea!

I am all for this. It shouldn’t be too complicated to add a second implicit 
import and only code that is actually using this stuff will have increased code 

> On Jan 9, 2018, at 10:29 PM, Chris Lattner via swift-evolution 
> <swift-evolution@swift.org> wrote:
> Disclaimer: I’m reordering your comments below to suit my nefarious purposes: 
> :-)
> On Jan 9, 2018, at 3:48 PM, Ben Cohen <ben_co...@apple.com> wrote:
>>> 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.
> Ok, I understand that (among all the other things going on that are clearly 
> more important) revamping this is probably not the highest priority thing to 
> do.  That said, it would be really unfortunate to carry around these 
> “suboptimal” APIs forever, particularly given how marginal they are (as in, 
> not widely used).  I’m sure that there are other examples beyond these that 
> are similarly unfortunate.
> Given that, I have a meta question for you: have you considered an approach 
> where you take the Swift standard library and split it into two conceptual 
> pieces:
> 1) The "ABI stable” subset of the library that gets burned into the OS.
> 2) The “ABI unstable” subset, which gets statically linked into apps, just 
> like the Swift 4 library used to?
> Given that “import Swift” is implicit anyway, you could just have the 
> compiler implicitly import *both* of these modules.  
> The point of doing this is that it gives you a very general and low friction 
> way to handle compatibility gunk.  In addition to putting obscure stuff like 
> Mirror and “DictionaryLiteral” into this (without breaking source code!) you 
> now get the ability to put the various deprecated forwarding functions in 
> this module as well, avoiding them becoming part of the ABI.
> The nice thing about this is that only people who use these things would have 
> to pay the cost, and you can directly message this by deprecating all the 
> stuff in it.  Think about it as an overlay for the Swift standard library :-)
>>> +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.
> I’m generally in agreement with you, but in this specific case, I seriously 
> doubt people are using this.  All rules are malleable in the right 
> circumstances.
> More importantly though, if we had a meta design that allowed to gracefully 
> phase this sort of thing out (without it becoming part of ABI under any name) 
> there becomes very little cost to leaving it around in the “abi unstable” 
> library for…. ever if need be.  Given that, I would have much less objection 
> to keeping it around.
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

swift-evolution mailing list

Reply via email to