<div dir="ltr">Unavailable doesn&#39;t mean un-callable.<div><div><ul><li>If you&#39;re marking an override or required initialiser as unavailable, it&#39;s still possible it&#39;s called dynamically, or by super.</li><li>If you&#39;re marking it unavailable for some OS versions, it could still be called by the other OS versions.</li><li>If it&#39;s neither of those two categories, you probably don&#39;t even need the function declaration.</li></ul></div><div>It&#39;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, &quot;<span style="font-size:13px">this is an example where concision is overrated</span>&quot;.</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">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; On Jun 10, 2016, at 2:22 PM, Austin Zheng via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt; Hello swift-evolutioneers,<br>
&gt;<br>
&gt; Here&#39;s an idea. It&#39;s technically additive, but it&#39;s small and I think it fits in well with Swift 3&#39;s goals, one of which is to establish API conventions.<br>
&gt;<br>
&gt; Right now, you can declare a function, type member, etc and mark it using &quot;@available(*, unavailable, renamed:&quot;someNewName()&quot;)&quot;. 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>
&gt;<br>
&gt; 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>
&gt;<br>
&gt; 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>
&gt;<br>
&gt; So, instead of:<br>
&gt;<br>
&gt; @available(*, unavailable, renamed:&quot;someNewAPI()&quot;)<br>
&gt; public func someOldAPI() -&gt; Int { fatalError() }<br>
&gt;<br>
&gt; You can just have:<br>
&gt;<br>
&gt; @available(*, unavailable, renamed:&quot;someNewAPI()&quot;)<br>
&gt; public func someOldAPI() -&gt; Int<br>
&gt;<br>
&gt; The intent is, in my opinion, clearer for the latter and it feels less kludgy.<br>
&gt;<br>
&gt; 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&#39;re require to implement an always-unavailable function.  We can take it through evolution anyway, though.<br>
<br>
John.<br>
<br>
&gt;<br>
&gt; Best,<br>
&gt; Austin<br>
<div class="HOEnZb"><div class="h5">&gt;<br>
&gt; _______________________________________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
&gt; <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>