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

[Austin Zheng]

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/9acfea0f/attachment.html>