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

Austin Zheng austinzheng at gmail.com
Fri Jun 10 16:22:13 CDT 2016


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?

Best,
Austin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160610/9a7d7bcb/attachment.html>


More information about the swift-evolution mailing list