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

[Dave Abrahams]

on Fri Aug 12 2016, Ben Rimmington <swift-evolution at swift.org> wrote:

>> On 12 Aug 2016, at 21:03, Dave Abrahams wrote:
>> 
>>> on Fri Aug 12 2016, Ben Rimmington wrote:
>>> 
>>>> On 9 Aug 2016, at 20:09, Dave Abrahams wrote:
>
>>>> 
>>>> 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.
>>> 
>>> Can the deprecation of ExpressibleByStringInterpolation be reverted next year,
>>> if a backwards-compatible design is proposed for Swift 4.0?
>> 
>> Yes, that's the plan, even if a backwards-compatible design isn't
>> proposed.  The reason to deprecate it now is that we're not sure a
>> backwards-compatible design will be possible.
>
> The only downside is when manually converting to current Swift syntax:
>
> 1. ⚠️ 'StringInterpolationConvertible' is deprecated: 
>     renamed to 'ExpressibleByStringInterpolation'
>
> 2. ☑️ Fix-it: Use 'ExpressibleByStringInterpolation' instead
>
> 3. ⚠️ 'ExpressibleByStringInterpolation' is deprecated: 
>     it will be replaced or redesigned in Swift 4.0.  
>     Instead of conforming to 'ExpressibleByStringInterpolation', 
>     consider adding an 'init(_:String)'

That's bad; we'll make sure to update the unavailable annotation for
StringInterpolationConvertible so this doesn't happen!

-- 
-Dave