<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">@noreturn func error<T>(msg: String = "") -> T {<br> fatalError("bottom: \(msg)")<br>}<br>has to be written as<br>func error<T>(msg: String = "") -> T {<br> fatalError("bottom: \(msg)")<br>}<br>It still returns bottom, but there is no way to say so in the declaration. The proposal just made the language less expressive!</blockquote><div><br></div><div>Do we need to? One of use cases of this feature is to prototype using unimplemented functions, i.e. lying about return type. In other cases, return type of this function should be NoReturn/Never, as well.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">You can write a foo-function that is really unintuitive:<br>func foo() -> NoReturn {<br> let x = fatalError("crash please")<br> print("1+1=2")<br> return x<br>}</blockquote><div><br></div><div>This is called "unreachable code", and this should give the same warning as is currently given in such cases. Also you can currently create sufficiently complex unreachable code that does not trigger a warning, and nothing will change in that aspect.</div><div><br></div><div>Thinking about bottom-like behaviour, it would be a strict extension of functionality of Never, so it can be discussed later in a separate proposal.</div><div><br></div><div>- Anton</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-06 22:40 GMT+03:00 Michael Peternell <span dir="ltr"><<a href="mailto:michael.peternell@gmx.at" target="_blank">michael.peternell@gmx.at</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> Am 06.06.2016 um 00:53 schrieb Charles Srstka <<a href="mailto:cocoadev@charlessoft.com">cocoadev@charlessoft.com</a>>:<br>
><br>
>> On Jun 5, 2016, at 5:41 PM, Michael Peternell via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>>> Am 05.06.2016 um 20:26 schrieb Антон Жилин via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br>
>>><br>
>>> The following names were suggested: NoReturn, Bottom, None, Never.<br>
>>> I would pick None, because it looks like opposite to Any and fits nicely in generic types.<br>
>><br>
>> I would like to call the type `Void`. `Void` is a type with zero possible values. The current `Void` would have to be renamed to `Unit`, the data type with exactly one possible value. Less C, More Haskell :) But wait, that's not really Haskell-ish, and it's not C-ish either.<br>
><br>
> That is the most confusing possible thing that this could possibly be called. Seeing a Void return will cause anyone coming from a C, C++, ObjC, etc. background to think of something that is definitely *not* a no-return function.<br>
<br>
</span>I agree. For this reason, my email continued after that paragraph. I deliberately ended the last sentence of that paragraph with "But wait, that's not really..."<br>
<br>
There is a really really good reason why Haskell doesn't have a named "bottom type" like "None" or "Void". The bottom type has type `forall a. a`, corresponding to the mathematical fact that from "false" follows anything. Assigning a bottom type to a variable makes only sense in Haskell, because it uses lazy evaluation. With strict evaluation, a bottom type is just confusing at best. And a `Nothing` type corresponds to Haskell's `Void` type, not to its bottom type - a really exotic type that is seldom used. Its not consistent to have a @noreturn-function return `Nothing` instead, because `Nothing` that's not a proper type. You can write a foo-function that is really unintuitive:<br>
<span class=""><br>
func foo() -> NoReturn {<br>
let x = fatalError("crash please")<br>
print("1+1=2")<br>
return x<br>
}<br>
<br>
</span>Shouldn't we all just try to understand the rationale for the current language behavior before we try to propose changes?<br>
<br>
E.g. with the proposal, the following function:<br>
<br>
@noreturn func error<T>(msg: String = "") -> T {<br>
fatalError("bottom: \(msg)")<br>
}<br>
<br>
has to be written as<br>
<br>
func error<T>(msg: String = "") -> T {<br>
fatalError("bottom: \(msg)")<br>
}<br>
<br>
It still returns bottom, but there is no way to say so in the declaration. The proposal just made the language less expressive!<br>
<br>
See also:<br>
<a href="https://en.wikibooks.org/wiki/Haskell/Denotational_semantics" rel="noreferrer" target="_blank">https://en.wikibooks.org/wiki/Haskell/Denotational_semantics</a><br>
for a more in-depth explanation why "bottom" is not an ordinary type with a name.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Michael<br>
<br>
</font></span></blockquote></div><br></div>