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

[John McCall]

> 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.

John.

> 
> Best,
> Austin
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution