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" <[email protected]>
Sent: 10/06/2016 06:42 PM
To: "Leonardo Pessoa" <[email protected]>
Cc: "Erica Sadun" <[email protected]>; "swift-evolution"
<[email protected]>
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 <[email protected]> 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
<[email protected]> wrote:
> On Jun 10, 2016, at 3:22 PM, Austin Zheng via swift-evolution
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
>_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
