<div dir="ltr">NSUnimplemented() has nothing to do with the Swift compiler proper, and you won't find it in the Swift repo. It's a marker used for the Swift Foundation project to denote methods and APIs that haven't yet been implemented. It has nothing to do with availability/renamed.<div><br></div><div>As for the overhead, I don't understand this argument either. Today, the compiler already has to cross-check the use of an API against a list of whether or not it's been blacklisted using "unavailable". If it's "unavailable" the compiler stops with an error and does not need to further check whether a function body has been defined. As for the grammar, there are already productions defined for member declarations without implementations, used for constructing protocols.</div><div><br></div><div>Austin</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 10, 2016 at 2:32 PM, Leonardo Pessoa <span dir="ltr"><<a href="mailto:me@lmpessoa.com" target="_blank">me@lmpessoa.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've seen around the Swift source code some uses of a function named<br>
something like NSUnimplemented(). I'm not sure this is available only<br>
inside the Swift source or if we could call it as well (I'm not in<br>
front of a Swift compiler right now so I cannot test).<br>
<br>
The idea of being able to drop the body of the function is interesting<br>
but I keep thinking of the overhead of the compiler to check for every<br>
function if it can drop the requirement for a body. Perhaps keeping<br>
the body is well suited here.<br>
<br>
On 10 June 2016 at 18:26, Erica Sadun via swift-evolution<br>
<div><div class="h5"><<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
> On Jun 10, 2016, at 3:22 PM, Austin Zheng via swift-evolution<br>
> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<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<br>
> kludgy.<br>
><br>
><br>
> You ask, we answer. I'd much prefer spelling out { fatalError("unavailable<br>
> API") }.<br>
> It makes the code clearer to read, to maintain, it produces debug and<br>
> runtime errors. etc. I think<br>
> this is an example where concision is overrated.<br>
><br>
> -- E<br>
><br>
><br>
><br>
</div></div>> _______________________________________________<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>
</blockquote></div><br></div></div>