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 size.
> 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
