[swift-evolution] [Late Pitch] Deprecations, Moves, and Renames
dabrahams at apple.com
Sat Aug 13 15:56:39 CDT 2016
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!
More information about the swift-evolution