[swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

Xiaodi Wu xiaodi.wu at gmail.com
Tue Aug 9 14:50:12 CDT 2016


+1. All seems reasonable to me.
On Tue, Aug 9, 2016 at 14:16 Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

>
> Hi Everybody,
>
> With another round of apologies for taking late action, we propose to
> make some deprecations, moves, and renames.  The background for these
> moves is as follows:
>
> We've always known that when Swift reached ABI stability (now slated for
> Swift 4), we would be committed to supporting many of the standard
> library's design decisions for years to come.  What we only realized
> very recently is that, although Swift 3.0 is *not* shipping with a
> stable ABI, the promise that Swift 3.0 code will work with Swift 4.0
> code creates similar implications when it comes to certain protocols,
> today.  Especially where these protocols show up in refinement
> hierarchies, we can't keep Swift 3 code working in the future without
> carrying them forward into future libraries.
>
> The proposed changes are as follows:
>
> * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.
>   This component is really only useful for playgrounds, and doesn't
>   belong in the standard library.
>
> * Deprecate the Indexable protocols with a message indicating that they
>   will be gone in Swift 4.  These protocols are implementation details
>   of the standard library designed to work around language limitations
>   that we expect to be gone in Swift 4.  There's no reason for anyone to
>   ever touch these; users should always use a corresponding Collection
>   protocol (e.g. instead of MutableIndexable, use MutableCollection).
>
> * Deprecate the ExpressibleByStringInterpolation protocol with a
>   message indicating that its design is expected to change.  We know
>   this protocol to be mis-designed
>   (https://bugs.swift.org/browse/SR-1260) and limited
>   (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
>   for Swift 3.  If we knew what the new design should look like, we
>   might be able to calculate that the current API is supportable in a
>   forward-compatible way (as we do for Comparable).  Unfortunately, we
>   do not.
>
> * Rename Streamable to TextOutputStreamable and add a deprecated
>   Streamable typealias for it.  Now that OutputStream been renamed to
>   TextOutputStream, we should also move Streamable out of the way.
>
> Deprecation is being proposed instead of underscoring or renaming
> because it allows existing code to keep working (with warnings).  At
> this late stage, it would be bad to actually break anything.
>
> --
> -Dave
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160809/67f63273/attachment.html>


More information about the swift-evolution mailing list