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

Leonardo Pessoa me at lmpessoa.com
Fri Jun 10 17:03:50 CDT 2016


The thing with NSUnimplemented was really just a mention and nothing to do with the issue.

As for the real issue, the blacklist you mention is formed after parsing the source. That's how compilers usually work. The function impl is expected due to the syntax definition that is checked during the parsing phase and before that blacklist is formed. Thus one would have to flex the syntax and allow every func to not have a body and only after parsing the source check if the func had or not to have a body based on the unavailable attribute. That is unless the compiler analyses the source code while it's being parsed and I don't believe the Swift compiler does that (I haven't been that down the rabbit hole so I'm not affirming). Please note that in not saying it cannot be done, only that there may be consequences.

L

-----Original Message-----
From: "Austin Zheng" <austinzheng at gmail.com>
Sent: ‎10/‎06/‎2016 06:42 PM
To: "Leonardo Pessoa" <me at lmpessoa.com>
Cc: "Erica Sadun" <erica at ericasadun.com>; "swift-evolution" <swift-evolution at swift.org>
Subject: Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need animpl

NSUnimplemented() has nothing to do with the Swift compiler proper, and you won't find it in the Swift repo. It's a marker used for the Swift Foundation project to denote methods and APIs that haven't yet been implemented. It has nothing to do with availability/renamed.


As for the overhead, I don't understand this argument either. Today, the compiler already has to cross-check the use of an API against a list of whether or not it's been blacklisted using "unavailable". If it's "unavailable" the compiler stops with an error and does not need to further check whether a function body has been defined. As for the grammar, there are already productions defined for member declarations without implementations, used for constructing protocols.


Austin


On Fri, Jun 10, 2016 at 2:32 PM, Leonardo Pessoa <me at lmpessoa.com> wrote:

I've seen around the Swift source code some uses of a function named
something like NSUnimplemented(). I'm not sure this is available only
inside the Swift source or if we could call it as well (I'm not in
front of a Swift compiler right now so I cannot test).

The idea of being able to drop the body of the function is interesting
but I keep thinking of the overhead of the compiler to check for every
function if it can drop the requirement for a body. Perhaps keeping
the body is well suited here.

On 10 June 2016 at 18:26, Erica Sadun via swift-evolution

<swift-evolution at swift.org> wrote:
> On Jun 10, 2016, at 3:22 PM, Austin Zheng via swift-evolution
> <swift-evolution at swift.org> wrote:
>
> 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.
>
>
> You ask, we answer. I'd much prefer spelling out { fatalError("unavailable
> API") }.
> It makes the code clearer to read, to maintain, it produces debug and
> runtime errors. etc. I think
> this is an example where concision is overrated.
>
> -- E
>
>
>

> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160610/72c8b870/attachment.html>


More information about the swift-evolution mailing list