[swift-evolution] [Late Pitch] Deprecations, Moves, and Renames
dabrahams at apple.com
Wed Aug 10 11:24:39 CDT 2016
on Wed Aug 10 2016, Ben Rimmington <me-AT-benrimmington.com> wrote:
>> On 10 Aug 2016, at 00:36, Dave Abrahams wrote:
>>> on Tue Aug 09 2016, Ben Rimmington wrote:
>>>> On 9 Aug 2016, at 20:09, Dave Abrahams 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.
>>> I didn't think it was possible to `import PlaygroundSupport` unless the
>>> current file is within a playground. If so, how can corelibs-foundation
>>> or third-party modules add `CustomPlaygroundQuickLookable`
>> Ahhh... yeah, I didn't realize that, and we don't have time to change
>> that restriction for Swift 3. It's not a problem for
>> corelibs-foundation but it would be for 3rd-party libraries.
>> OK, Dmitri and I just figured out how we can change the home of these
>> types for Swift 4 without breaking Swift 3 code (mirrors to the rescue!)
>> So I'm going to withdraw this part of the proposal.
> Will the following need to be reverted?
Technically, no, because typealiases make it unnecessary, but yes, we
plan to do that.
>>>> * 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.
> In apple/swift#4131, these lines have overrun the 80 column limit:
> TextFormatting.rst also needs `Streamable` => `TextOutputStreamable`:
Pull requests gratefully accepted for all of these corrections
>>>> 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.
>>> If the SE-0104 (protocol-oriented integers) proposal has been deferred,
>>> should any protocols (e.g. SignedNumber) be deprecated?
> Will the SE-0104 proposal be accepted for Swift 4.0?
It is expected to be. We may even be able to get it into a Swift 3
point-release (e.g. 3.1)
More information about the swift-evolution