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

[Dave Abrahams]

on Wed Aug 10 2016, Dave Abrahams <swift-evolution at swift.org> wrote:

> 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`
>>>> conformance?
>>> 
>>> 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?
>>
>> <https://github.com/apple/swift/pull/4089>
>>
>> <https://github.com/apple/swift-xcode-playground-support/commit/aab7af4>
>> <https://github.com/apple/swift-xcode-playground-support/commit/865fd0c>
>> <https://github.com/apple/swift-xcode-playground-support/commit/ab605ef>
>> <https://github.com/apple/swift-xcode-playground-support/commit/4bd6575>
>> <https://github.com/apple/swift-xcode-playground-support/commit/acee2e1>
>
> Technically, no, because typealiases make it unnecessary, but yes, we
> plan to do that.

done: https://github.com/apple/swift-xcode-playground-support/commit/0f42ade5a6302cf953a3ed32a892f23e8e150c62

>>>>> * 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:
>>
>> <https://github.com/apple/swift/blob/f2443f4/stdlib/public/core/Mirror.swift#L843>
>> <https://github.com/apple/swift/blob/f2443f4/stdlib/public/core/Mirror.swift#L893>
>>
>> <https://github.com/apple/swift/blob/f2443f4/stdlib/public/core/Print.swift#L177>
>> <https://github.com/apple/swift/blob/f2443f4/stdlib/public/core/Print.swift#L228>
>>
>> TextFormatting.rst also needs `Streamable` => `TextOutputStreamable`:
>>
>> <https://github.com/apple/swift/blob/master/docs/TextFormatting.rst>
>
> 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)

-- 
-Dave