<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Jun 10, 2016 at 3:03 PM Leonardo Pessoa via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><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></div></div></div></blockquote><div><br></div><div>It seems like the whole "has a body" thing only really matters in the case of non-Void functions, because a Void function can simply do this:</div><div><br></div><div><div> @available(*, unavailable, renamed:"someNewAPI()")</div><div> public func someOldAPI() {}</div></div><div><br></div><div>The extra two characters (three, if you count the space), don't seem like the end of the world there.</div><div><br></div><div>So, what if unavailable functions were implicitly @noreturn, since that's effectively what you're doing by calling fatalError anyway? Then you could write {} even for value-returning functions, and it happens at the semantic analysis phase where that contextual information is available, rather than at the syntactic analysis phase.</div><div><br></div><div> </div><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"><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><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>_______________________________________________<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>
</blockquote></div></div>