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

[Tim Vermeulen]

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?

> 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.
> 
> > > > > * 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
> 
> 
>