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

[Dave Abrahams]

on Tue Aug 09 2016, Ben Rimmington <swift-evolution at swift.org> 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.

>> * 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.
>> 
>> 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?
>
> -- Ben
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave