<div dir="ltr">I won't speculate more about the internals of the compiler, since (like you) I haven't gone far enough into the code to know how it works in this regard.<div><br></div><div>However, if it really is something that the current architecture can't easily support, I'd be happy for one of the compiler engineers to jump in and nix the proposal, or for the proposal to be dismissed after five minutes of deliberation when it goes up for review. Worrying about implementation cost without understanding whether it would actually be a problem is premature.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 10, 2016 at 3:03 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"><div><div><div style="font-family:Calibri,sans-serif;font-size:11pt">The thing with NSUnimplemented was really just a mention and nothing to do with the issue.<br><br>As for the real issue, the blacklist you mention is formed after parsing the source. That's how compilers usually work. The function impl is expected due to the syntax definition that is checked during the parsing phase and before that blacklist is formed. Thus one would have to flex the syntax and allow every func to not have a body and only after parsing the source check if the func had or not to have a body based on the unavailable attribute. That is unless the compiler analyses the source code while it's being parsed and I don't believe the Swift compiler does that (I haven't been that down the rabbit hole so I'm not affirming). Please note that in not saying it cannot be done, only that there may be consequences.<br><br>L</div></div><div dir="ltr"><hr><span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">From: </span><span style="font-family:Calibri,sans-serif;font-size:11pt"><a href="mailto:austinzheng@gmail.com" target="_blank">Austin Zheng</a></span><br><span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">Sent: </span><span style="font-family:Calibri,sans-serif;font-size:11pt">10/06/2016 06:42 PM</span><br><span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">To: </span><span style="font-family:Calibri,sans-serif;font-size:11pt"><a href="mailto:me@lmpessoa.com" target="_blank">Leonardo Pessoa</a></span><br><span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">Cc: </span><span style="font-family:Calibri,sans-serif;font-size:11pt"><a href="mailto:erica@ericasadun.com" target="_blank">Erica Sadun</a>; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution</a></span><br><span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">Subject: </span><span style="font-family:Calibri,sans-serif;font-size:11pt">Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need animpl</span><br><br></div><div><div class="h5"><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:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">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><<a href="mailto:swift-evolution@swift.org" target="_blank">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" target="_blank">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" target="_blank">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>
</div></div></div></blockquote></div><br></div>