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

Chris Lattner clattner at apple.com
Fri Sep 9 13:10:48 CDT 2016


> On Sep 9, 2016, at 4:11 AM, Tim Vermeulen <tvermeulen at me.com> wrote:
> 
> Actually, it seems as though they are only in the development snapshot, and not the default Xcode 8.0 toolchain. I didn’t realise the development snapshots already included things for beyond Swift 3.0.

Right.  Master and the development snapshots that come from it include things beyond Swift 3.

-Chris

> 
>> On 9 Sep 2016, at 01:35, Chris Lattner <clattner at apple.com <mailto: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/cad4d9e3/attachment.html>


More information about the swift-evolution mailing list