> On Jan 9, 2018, at 11:48 AM, Chris Lattner <clatt...@nondot.org> wrote: > >> On Jan 9, 2018, at 10:23 AM, Ben Cohen <ben_co...@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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
