[swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

[Chris Lattner]

> On Jun 10, 2016, at 5:47 PM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Jun 10, 2016, at 2:22 PM, Austin Zheng via swift-evolution <swift-evolution at 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