[swift-evolution] [Draft] Change @noreturn to unconstructible return type

[Vladimir.S]

My opinion is based on this message:

On 05.06.2016 23:16, L. Mihalkovic via swift-evolution wrote:
 >
 > FWIW, in the rejection of SE-0097
 > 
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019879.html>,
 > this was what the core team had to say about it:
 >
 >     /1) For noreturn, the core team prefers to explore a solution where a
 >     function can be declared as returning an non-constructable “bottom”
 >     type (e.g. an enum with zero cases).  This would lead to something 
like:/
 >     /
 >     /
 >     /func abort() -> NoReturn { … }/

I.e. we need some type that will reflect "NoReturn" at first. Then, 
probably, it can be used as bottom type. IMO `Never` is the best candidate 
at this moment. For me it also can mean "never can have an instance of this 
type" or "never be created" or "never be user" etc

On 06.06.2016 18:26, Tony Allevato wrote:
> "Nothing" feels like it collides too much with the concept of a function
> that returns, but returns nothing (i.e., Void), however.
>
> If I read a function declaration from left to right:
>
>     func foo() -> Nothing
>
> I read that as "a function foo that returns nothing". That sounds like a
> Void function to me. On the other hand:
>
>     func foo() -> Never
>
> I read that as "a function foo that returns never". That's perfectly clear
> to me.
>
> When it comes to naming things like this, I don't think we should try to
> shoehorn in the arguably more "pure" names when it runs the risk of causing
> confusion with Swift's C-based ancestry. 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. The main audience here is still app developers and
> perhaps backend developers, not academics.
>
> On Mon, Jun 6, 2016 at 8:16 AM Charlie Monroe via swift-evolution
> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>
>     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.
>
>     It should be the opposite of Any, which (excluding None), seems to be
>     Nothing. Or Singularity :)
>
>     6. 6. 2016 v 16:12, Vladimir.S via swift-evolution
>     <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>
>     > +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.
>     >
>     >> On 06.06.2016 16:37, Thorsten Seitz via swift-evolution wrote:
>     >> My preference from the current suggestions would be Never.
>     >>
>     >> -Thorsten
>     >>
>     >>> Am 06.06.2016 um 15:24 schrieb Thorsten Seitz via swift-evolution
>     <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>     >>>
>     >>> Ceylon uses `Nothing` for the bottom type.
>     >>>
>     >>> -Thorsten
>     >>>
>     >>>> Am 05.06.2016 um 20:39 schrieb Charlie Monroe via swift-evolution
>     <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>     >>>>
>     >>>> 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.
>     >>>>
>     >>>> 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.
>     >>>>
>     >>>> Or "Nothing" as in Scala.
>     >>>>
>     >>>>> On Jun 5, 2016, at 8:26 PM, Антон Жилин via swift-evolution
>     <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>     >>>>>
>     >>>>> The following names were suggested: NoReturn, Bottom, None, Never.
>     >>>>> I would pick None, because it looks like opposite to Any and fits
>     nicely in generic types.
>     >>>>>
>     >>>>> I would prefer the type to be simple, and be implemented as a
>     case-less enum (not a bottom value, as in Haskell).
>     >>>>>
>     >>>>> None should be a usual enum, with no compiler magic except that
>     functions returning None are equivalent to current @noreturn.
>     >>>>>
>     >>>>> Example 1.
>     >>>>> let x: None?
>     >>>>> // ...
>     >>>>> let y = x!
>     >>>>>
>     >>>>> 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.
>     >>>>> We could prove that it is always true in this case, but compiler
>     must be stupid about this.
>     >>>>>
>     >>>>> Example 2.
>     >>>>> Compiler should allow including None in structures. Error will
>     show up in constructor, when we will not be able to initialize the field.
>     >>>>>
>     >>>>> Example 3.
>     >>>>> None in an enum case makes that case never appear in values of
>     such a type. But compiler can not know about that.
>     >>>>>
>     >>>>> - Anton
>     >>>>> _______________________________________________
>     >>>>> swift-evolution mailing list
>     >>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>     >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>     >>>>
>     >>>> _______________________________________________
>     >>>> swift-evolution mailing list
>     >>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>     >>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>     >>> _______________________________________________
>     >>> swift-evolution mailing list
>     >>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>     >>> https://lists.swift.org/mailman/listinfo/swift-evolution
>     >> _______________________________________________
>     >> swift-evolution mailing list
>     >> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>     >> https://lists.swift.org/mailman/listinfo/swift-evolution
>     > _______________________________________________
>     > swift-evolution mailing list
>     > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>     > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>     _______________________________________________
>     swift-evolution mailing list
>     swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>     https://lists.swift.org/mailman/listinfo/swift-evolution
>