> On Mar 16, 2016, at 11:46 PM, Adrian Kashivskyy via swift-evolution > <[email protected]> wrote: > > @Jed, > >> That said, the problem isn’t necessarily difficult to solve — it’s just that >> it’s important that it actually be solved at the same time the feature is >> rolled out. > > I cannot speak for Apple, but judging from last Swift releases where SDKs > were always up-to-date with latest Swift changes, I believe this change will > be reflected as well.
OS SDKs don't turn on a dime so this is a reasonable concern. We don't want to ship an Xcode package with Swift and SDKs that don't play well together. (Those of you in bleeding-edge open source land are not so lucky…) For this feature there are feasible adoption paths even if the SDK updates slowly so we should be okay. If we can't get enough of the SDK to adapt in time then we can make the change in stages, deferring complete adoption until the SDK can catch up. For this feature one interim measure would be to temporarily accept both @warn_unused_result and @discardable, add a temporary compiler flag to choose what the default is for unmarked functions, and set the flag to the old way by default. Then the new SDK could update their code while the old SDK still works. Once the SDK was ready we could remove @warn_unused_result and the compiler flag. A simpler staged adoption would be to temporarily accept both @warn_unused_default and @discardable, but ignore them both. The downside there is that we would temporarily get no unused result warnings at all, which sounds bad. In any case the problem of SDK malleability is not a show-stopper for acceptance of this proposal. It's not hard to make it work. -- Greg Parker [email protected] <mailto:[email protected]> Runtime Wrangler
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
