> 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 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.

> 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 
> <[email protected] <mailto:[email protected]>> 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 <[email protected] 
> <mailto:[email protected]>>:
> 
> > +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 
> >>> <[email protected] <mailto:[email protected]>>:
> >>>
> >>> Ceylon uses `Nothing` for the bottom type.
> >>>
> >>> -Thorsten
> >>>
> >>>> Am 05.06.2016 um 20:39 schrieb Charlie Monroe via swift-evolution 
> >>>> <[email protected] <mailto:[email protected]>>:
> >>>>
> >>>> 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 
> >>>>> <[email protected] <mailto:[email protected]>> 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
> >>>>> [email protected] <mailto:[email protected]>
> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
> >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> >>>>
> >>>> _______________________________________________
> >>>> swift-evolution mailing list
> >>>> [email protected] <mailto:[email protected]>
> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
> >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> >>> _______________________________________________
> >>> swift-evolution mailing list
> >>> [email protected] <mailto:[email protected]>
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution 
> >>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> [email protected] <mailto:[email protected]>
> >> https://lists.swift.org/mailman/listinfo/swift-evolution 
> >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> > _______________________________________________
> > swift-evolution mailing list
> > [email protected] <mailto:[email protected]>
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to