<div dir="ltr">On Mon, Jun 6, 2016 at 10:39 AM, Charlie Monroe via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><blockquote type="cite"><div dir="ltr"><div>I'd argue that it's more important for the language to be clearly readable than to satisfy a notion of absolute adherence to pure formal semantics that only theorists would completely understand.</div></div></blockquote><div><br></div></span><div>The semantics might help a person better understand the philosophy of the language. The @noreturn methods are *not* being written very often, and definitely not by newcomers, who are usually fine knowing there's fatalError and that's it. For a person who has a deeper insight into the language, semantic consistency may be good thing.</div></div></div></blockquote><div><br></div><div>No, but it will be *read* by many, and those who are reading but not writing these methods are particularly in need of clarity as to what it does. A distinction between a method that returns None vs. a method that returns Void is going to be ridiculously nonsensical for such a user.</div><div><br></div><div>In any case, if we need a 'consistent' word, `Never` can be paired with `Every`.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div class="h5"><br><blockquote type="cite"><div dir="ltr"><div> The main audience here is still app developers and perhaps backend developers, not academics.</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 6, 2016 at 8:16 AM Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">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">You are thinking of it as a return type, but that's not how you should think of it, really - that's an example of what it may be used for, but it should not be the only aspect.<br>
<br>
It should be the opposite of Any, which (excluding None), seems to be Nothing. Or Singularity :)<br>
<br>
6. 6. 2016 v 16:12, Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>:<br>
<br>
> +1 for Never, as 'foo() -> Never' reads as 'foo returns never' i.e. close to 'never returns'. Or we just need NoReturn as replacement for @noreturn, and then think about true bottom type and its name separately.<br>
><br>
>> On 06.06.2016 16:37, Thorsten Seitz via swift-evolution wrote:<br>
>> My preference from the current suggestions would be Never.<br>
>><br>
>> -Thorsten<br>
>><br>
>>> Am 06.06.2016 um 15:24 schrieb Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>:<br>
>>><br>
>>> Ceylon uses `Nothing` for the bottom type.<br>
>>><br>
>>> -Thorsten<br>
>>><br>
>>>> Am 05.06.2016 um 20:39 schrieb Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>:<br>
>>>><br>
>>>> While None is probably the best way to describe the opposite of Any, it would be often mistaken for .None (i.e. Optional) by newcomers to the language.<br>
>>>><br>
>>>> I'd personally prefer calling it "Nil" (capital N), which really means "nonexistent". The same way ObjC had "nil" for "id" and "Nil" for Class. Possibly, to avoid confusion with nil, calling it Null? Though that might get confused with NSNull, once the NS prefix gets dropped.<br>
>>>><br>
>>>> Or "Nothing" as in Scala.<br>
>>>><br>
>>>>> On Jun 5, 2016, at 8:26 PM, Антон Жилин via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<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 prefer the type to be simple, and be implemented as a case-less enum (not a bottom value, as in Haskell).<br>
>>>>><br>
>>>>> None should be a usual enum, with no compiler magic except that functions returning None are equivalent to current @noreturn.<br>
>>>>><br>
>>>>> Example 1.<br>
>>>>> let x: None?<br>
>>>>> // ...<br>
>>>>> let y = x!<br>
>>>>><br>
>>>>> It will trap in runtime not because we discover scary bottom thing, as in Haskell, but because x had value Optional.none at that moment and we asserted otherwise.<br>
>>>>> We could prove that it is always true in this case, but compiler must be stupid about this.<br>
>>>>><br>
>>>>> Example 2.<br>
>>>>> Compiler should allow including None in structures. Error will show up in constructor, when we will not be able to initialize the field.<br>
>>>>><br>
>>>>> Example 3.<br>
>>>>> None in an enum case makes that case never appear in values of such a type. But compiler can not know about that.<br>
>>>>><br>
>>>>> - Anton<br>
>>>>> _______________________________________________<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>
>>>> _______________________________________________<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>
>>> 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>
>> 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>
> 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>
<br>
_______________________________________________<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>
</blockquote></div></div></div><br></div><br>_______________________________________________<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>