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

[Charlie Monroe]

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 at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
> > On Jun 10, 2016, at 2:22 PM, Austin Zheng via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20160613/0058db87/attachment.html>