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

[Austin Zheng]

I won't speculate more about the internals of the compiler, since (like
you) I haven't gone far enough into the code to know how it works in this
regard.

However, if it really is something that the current architecture can't
easily support, I'd be happy for one of the compiler engineers to jump in
and nix the proposal, or for the proposal to be dismissed after five
minutes of deliberation when it goes up for review. Worrying about
implementation cost without understanding whether it would actually be a
problem is premature.

On Fri, Jun 10, 2016 at 3:03 PM, Leonardo Pessoa <me at lmpessoa.com> 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.
>
> 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
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160610/10bdf5a5/attachment-0001.html>