on Fri Aug 12 2016, Ben Rimmington <swift-evolution@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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution