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

Fri Sep 9 06:09:19 CDT 2016

The new integer protocols (Arithmetic, FixedWidthInteger, etc) aren’t supposed to be in Swift 3.0, right? They show up in the latest snapshot.

> On 9 Sep 2016, at 01:35, Chris Lattner <clattner at apple.com> wrote:
> 
> On Sep 7, 2016, at 12:58 PM, Tim Vermeulen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> They’re still in Swift 3. Did something go wrong, or will they simply not show up in the final Swift 3.0?
> 
> Please elaborate on what you mean: what is in that shouldn’t be?
> 
> -Chris
> 
>> 
>>> On 10 Aug 2016, at 22:28, Dave Abrahams <dabrahams at apple.com <mailto:dabrahams at apple.com>> wrote:
>>> 
>>> 
>>> on Wed Aug 10 2016, Tim Vermeulen <tvermeulen-AT-me.com <http://tvermeulen-at-me.com/>> wrote:
>>> 
>>>> Some protocols of SE-0104 seem to be part of the latest Swift 3
>>>> snapshots (Arithmetic, FixedWidthInteger, etc) - was this a mistake
>>>> then, if they won’t be in Swift 3.0?
>>> 
>>> Yes, they've been pulled out of the release branch:
>>> https://github.com/apple/swift/pull/4112#issuecomment-238451509 <https://github.com/apple/swift/pull/4112#issuecomment-238451509>
>>> 
>>>> 
>>>> 
>>>>> on Wed Aug 10 2016, Ben Rimmington<me-AT-benrimmington.com <http://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/pull/4089>>
>>>>>> 
>>>>>> <https://github.com/apple/swift-xcode-playground-support/commit/aab7af4 <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/865fd0c>>
>>>>>> <https://github.com/apple/swift-xcode-playground-support/commit/ab605ef <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/4bd6575>>
>>>>>> <https://github.com/apple/swift-xcode-playground-support/commit/acee2e1 <https://github.com/apple/swift-xcode-playground-support/commit/acee2e1>>
>>>>> 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 <https://bugs.swift.org/browse/SR-1260>) and limited
>>>>>>>>> (https://bugs.swift.org/browse/SR-2303 <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#L843>>
>>>>>> <https://github.com/apple/swift/blob/f2443f4/stdlib/public/core/Mirror.swift#L893 <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#L177>>
>>>>>> <https://github.com/apple/swift/blob/f2443f4/stdlib/public/core/Print.swift#L228 <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 <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
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> -- 
>>> -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/20160909/503cb34d/attachment.html>