<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">All I want, and all @available(*, unavailable, renamed:) gives me, is the ability to give my users a more pleasant upgrade experience than simply working through whatever errors Xcode spits out and trying to figure out what old APIs correspond with what new APIs.<div class=""><br class=""></div><div class="">If resilience is an issue...a library author can always simply choose to remove the old APIs altogether and break compatibility with older consumers. There is nothing Swift currently does to prevent this from happening, nor should it. If the library author wishes to forward use of unavailable APIs to their not-unavailable counterparts, that's their prerogative. There are a couple of other folks who are working on a resilience story for Swift (including things like versioning checks); until they have something to show us I don't see the point of worrying about maintaining resilience that Swift doesn't promise consumers of libraries to begin with.</div><div class=""><br class=""></div><div class="">Austin</div><div class=""><br class=""></div><div class=""><div class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Jun 10, 2016, at 6:51 PM, Andrew Bennett <<a href="mailto:cacoyi@gmail.com" class="">cacoyi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Unavailable doesn't mean un-callable.<div class=""><div class=""><ul class=""><li class="">If you're marking an override or required initialiser as unavailable, it's still possible it's called dynamically, or by super.</li><li class="">If you're marking it unavailable for some OS versions, it could still be called by the other OS versions.</li><li class="">If it's neither of those two categories, you probably don't even need the function declaration.</li></ul></div><div class="">It's not clear what default behaviour you would want in an unavailable method, calling super, calling a new method, a runtime error, ...<br class=""></div><div class=""><br class=""></div><div class="">An undefined implementation lacks clarity, as Erica says, "<span style="font-size:13px" class="">this is an example where concision is overrated</span>".</div></div><div class=""><div class=""><br class=""></div><div class=""><span style="" class="">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 class=""></div><div class=""><br class=""></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Jun 11, 2016 at 10:47 AM, John McCall via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><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" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> Hello swift-evolutioneers,<br class="">
><br class="">
> 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 class="">
><br class="">
> 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 class="">
><br class="">
> 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 class="">
><br class="">
> 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 class="">
><br class="">
> So, instead of:<br class="">
><br class="">
> @available(*, unavailable, renamed:"someNewAPI()")<br class="">
> public func someOldAPI() -> Int { fatalError() }<br class="">
><br class="">
> You can just have:<br class="">
><br class="">
> @available(*, unavailable, renamed:"someNewAPI()")<br class="">
> public func someOldAPI() -> Int<br class="">
><br class="">
> The intent is, in my opinion, clearer for the latter and it feels less kludgy.<br class="">
><br class="">
> What do people think? Are there any potential barriers (implementation or semantics) that would preclude this?<br class="">
<br class="">
</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 class="">
<br class="">
John.<br class="">
<br class="">
><br class="">
> Best,<br class="">
> Austin<br class="">
<div class="HOEnZb"><div class="h5">><br class="">
> _______________________________________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></div></body></html>