> On Jun 10, 2016, at 5:47 PM, John McCall via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>> On Jun 10, 2016, at 2:22 PM, Austin Zheng via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>> Hello swift-evolutioneers,
>>
>> Here's an idea. It's technically additive, but it's small and I think it
>> fits in well with Swift 3's goals, one of which is to establish API
>> conventions.
>>
>> Right now, you can declare a function, type member, etc and mark it using
>> "@available(*, unavailable, renamed:"someNewName()")". Doing so causes a
>> compile-time error if the user tries to use that member, and if you provide
>> the new name a fix-it is even generated telling you to use the new name.
>>
>> However, you can (and still need to) provide an implementation (e.g.
>> function body). You can just stick a fatalError() inside and be done with
>> it, but my question is, is an impl even necessary?
>>
>> My pitch is very simple: the declaration of any member marked with
>> @available(*, unavailable), or in other words marked as unavailable
>> regardless of platform or version, should be allowed to omit the
>> implementation.
>>
>> So, instead of:
>>
>> @available(*, unavailable, renamed:"someNewAPI()")
>> public func someOldAPI() -> Int { fatalError() }
>>
>> You can just have:
>>
>> @available(*, unavailable, renamed:"someNewAPI()")
>> public func someOldAPI() -> Int
>>
>> The intent is, in my opinion, clearer for the latter and it feels less
>> kludgy.
>>
>> What do people think? Are there any potential barriers (implementation or
>> semantics) that would preclude this?
>
> I actually just consider it a bug that you're require to implement an
> always-unavailable function. We can take it through evolution anyway, though.
I agree with John on both parts: it’s a bug, but considering it in evolution
makes sense.
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
