> 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.
John.
>
> Best,
> Austin
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
