[swift-evolution] [Late Pitch] Deprecations, Moves, and Renames
paulo at zewo.io
Tue Aug 9 18:11:53 CDT 2016
> 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.
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>> 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
>> 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>
> 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...
More information about the swift-evolution