<div dir="ltr">Unavailable doesn't mean un-callable.<div><div><ul><li>If you're marking an override or required initialiser as unavailable, it's still possible it's called dynamically, or by super.</li><li>If you're marking it unavailable for some OS versions, it could still be called by the other OS versions.</li><li>If it's neither of those two categories, you probably don't even need the function declaration.</li></ul></div><div>It's not clear what default behaviour you would want in an unavailable method, calling super, calling a new method, a runtime error, ...<br></div><div><br></div><div>An undefined implementation lacks clarity, as Erica says, "<span style="font-size:13px">this is an example where concision is overrated</span>".</div></div><div><div><br></div><div><span style="color:rgb(0,0,0)">Likewise, as Brent says, you may want the old unavailable API to call through to the new API. </span> A new version of a library may be dynamically linked by something compiled against an older version.<br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 11, 2016 at 10:47 AM, John McCall via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On Jun 10, 2016, at 2:22 PM, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> Hello swift-evolutioneers,<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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?<br>
><br>
> 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.<br>
><br>
> So, instead of:<br>
><br>
> @available(*, unavailable, renamed:"someNewAPI()")<br>
> public func someOldAPI() -> Int { fatalError() }<br>
><br>
> You can just have:<br>
><br>
> @available(*, unavailable, renamed:"someNewAPI()")<br>
> public func someOldAPI() -> Int<br>
><br>
> The intent is, in my opinion, clearer for the latter and it feels less kludgy.<br>
><br>
> What do people think? Are there any potential barriers (implementation or semantics) that would preclude this?<br>
<br>
</span>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.<br>
<br>
John.<br>
<br>
><br>
> Best,<br>
> Austin<br>
<div class="HOEnZb"><div class="h5">><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>