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

[Ben Rimmington]

> On 10 Aug 2016, at 22:44, Erica Sadun wrote:
> 
>> On Aug 9, 2016, at 1:09 PM, 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.
> 
> This seems like an obvious win. I *strongly* support this. (Didn't we discuss this
> several weeks ago?)

Yes, we did:

<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/025242.html>

But that part of the proposal has been withdrawn:

<https://github.com/apple/swift-evolution/commit/e2610e3fa91b437e06e768aaef6820d755489717>

> Since you've opened the doors to last minute discussions, I also feel quite strongly
> that image/color/file literals are misplaced and do not belong as part of the 
> standard library. The image one is the best example of the misfit. Images will probably 
> never be a core component of stdlib but they don't fit in PlaygroundSupport either as they 
> are essentially EditorSupport-ive. They have value across multiple platforms (currently
> OS X and the UIKit family, but primarily act in an Xcode-support role) but could be extended
> to other editors and other platforms. (And yes, I have list of other items but they fall well
> outside the scope of the current Swift Ev discussion so I'm sitting on them.)
> 
>> * 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).
> 
> It's time to for indices to evolve. 
> 
>> * 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.
> 
> I'm glad you're thinking forward about this.
> 
>> * 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.
> 
> Fine. Now if only I could figure out how to get this working. Been
> banging my head against the new streaming stuff. Also it shouldn't be
> this hard to print(....toStream: CustomCustomCustomBlah.stderr)

See the LocalFileOutputByteStream class and the `<<<` operator in:

<https://github.com/apple/swift-package-manager/blob/master/Sources/Basic/OutputByteStream.swift>

>> 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.
> 
> Sensible.
> 
> -- E