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

[Paulo Faria]

+1


> On Aug 9, 2016, at 6:57 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Tue Aug 09 2016, Karl <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>>> On 9 Aug 2016, at 21:09, 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
>> 
>> Does this include the ContiguousArray deprecation? 
> 
> Definitely not.
> 
>> I’m still seeing performance issues with regular Array (will update
>> bug soon).
>> 
>> I don’t mind if it gets deprecated, so long as it isn’t removed before we sort those issues out.
>> 
>> Otherwise +1
>> 
>> Karl
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/193da1f7/attachment.html>