As Andrew says - I have several cases where I mark a method on a subclass as
unavailable to ensure subclasses do not call it directly, but it is required by
the root class to be implemented (which it is and gets called).
Example:
class Root {
func doSomething() {
print("Root")
}
}
class Subclass {
@available(*, unavailable)
override func doSomething() {
super.doSomething()
print("Subclass")
}
}
And you can still do:
let instance: Root = Subclass()
instance.doSomething()
and it will call Root Subclass.
If it's renamed, you should really first deprecate it and just call the new API
and after a while make it unavailable with no change in the code.
If it's meant for abstract classes, then it's kind of a different issue.
> On Jun 11, 2016, at 3:51 AM, Andrew Bennett via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> 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@swift.org <mailto:swift-evolution@swift.org>> wrote:
> > On Jun 10, 2016, at 2:22 PM, Austin Zheng via swift-evolution
> > <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> > <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
