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
