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

[Tony Allevato]

On Fri, Jun 10, 2016 at 3:03 PM Leonardo Pessoa via swift-evolution <
swift-evolution at swift.org> wrote:

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

It seems like the whole "has a body" thing only really matters in the case
of non-Void functions, because a Void function can simply do this:

    @available(*, unavailable, renamed:"someNewAPI()")
    public func someOldAPI() {}

The extra two characters (three, if you count the space), don't seem like
the end of the world there.

So, what if unavailable functions were implicitly @noreturn, since that's
effectively what you're doing by calling fatalError anyway? Then you could
write {} even for value-returning functions, and it happens at the semantic
analysis phase where that contextual information is available, rather than
at the syntactic analysis phase.



>
> L
> ------------------------------
> 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
>> >
>>
>
> _______________________________________________
> 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/571f8763/attachment.html>