<div dir="ltr">Hello swift-evolutioneers,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>So, instead of:</div><div><br></div><div><div>@available(*, unavailable, renamed:&quot;someNewAPI()&quot;)</div><div>public func someOldAPI() -&gt; Int { fatalError() }</div></div><div><br></div><div>You can just have:</div><div><br></div><div><div>@available(*, unavailable, renamed:&quot;someNewAPI()&quot;)</div><div>public func someOldAPI() -&gt; Int</div></div><div><br></div><div>The intent is, in my opinion, clearer for the latter and it feels less kludgy.</div><div><br></div><div>What do people think? Are there any potential barriers (implementation or semantics) that would preclude this?</div><div><br></div><div>Best,</div><div>Austin</div><div><br></div></div>