[swift-evolution] [Late Pitch] Deprecations, Moves, and Renames
dabrahams at apple.com
Tue Aug 9 16:57:34 CDT 2016
on Tue Aug 09 2016, Karl <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?
> 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
More information about the swift-evolution