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

[Andrew Bennett]

Unavailable doesn't mean un-callable.

   - If you're marking an override or required initialiser as unavailable,
   it's still possible it's called dynamically, or by super.
   - If you're marking it unavailable for some OS versions, it could still
   be called by the other OS versions.
   - If it's neither of those two categories, you probably don't even need
   the function declaration.

It's not clear what default behaviour you would want in an unavailable
method, calling super, calling a new method, a runtime error, ...

An undefined implementation lacks clarity, as Erica says, "this is an
example where concision is overrated".

Likewise, as Brent says, you may want the old unavailable API to call
through to the new API.  A new version of a library may be dynamically
linked by something compiled against an older version.


On Sat, Jun 11, 2016 at 10:47 AM, John McCall via swift-evolution <
swift-evolution at swift.org> wrote:

> > On Jun 10, 2016, at 2:22 PM, Austin Zheng via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > Hello swift-evolutioneers,
> >
> > Here's an idea. It's technically additive, but it's small and I think it
> fits in well with Swift 3's goals, one of which is to establish API
> conventions.
> >
> > Right now, you can declare a function, type member, etc and mark it
> using "@available(*, unavailable, renamed:"someNewName()")". Doing so
> causes a compile-time error if the user tries to use that member, and if
> you provide the new name a fix-it is even generated telling you to use the
> new name.
> >
> > However, you can (and still need to) provide an implementation (e.g.
> function body). You can just stick a fatalError() inside and be done with
> it, but my question is, is an impl even necessary?
> >
> > My pitch is very simple: the declaration of any member marked with
> @available(*, unavailable), or in other words marked as unavailable
> regardless of platform or version, should be allowed to omit the
> implementation.
> >
> > 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.
> >
> > What do people think? Are there any potential barriers (implementation
> or semantics) that would preclude this?
>
> I actually just consider it a bug that you're require to implement an
> always-unavailable function.  We can take it through evolution anyway,
> though.
>
> John.
>
> >
> > Best,
> > Austin
> >
> > _______________________________________________
> > 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/20160611/5c3a3161/attachment.html>