On Mon, Jun 6, 2016 at 10:39 AM, Charlie Monroe via swift-evolution < [email protected]> wrote:
> 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. > 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. In any case, if we need a 'consistent' word, `Never` can be paired with `Every`. > 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]> 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]>: >> >> > +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]>: >> >>> >> >>> Ceylon uses `Nothing` for the bottom type. >> >>> >> >>> -Thorsten >> >>> >> >>>> Am 05.06.2016 um 20:39 schrieb Charlie Monroe via swift-evolution < >> [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]> 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] >> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >>>> >> >>>> _______________________________________________ >> >>>> swift-evolution mailing list >> >>>> [email protected] >> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >>> _______________________________________________ >> >>> swift-evolution mailing list >> >>> [email protected] >> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> >> swift-evolution mailing list >> >> [email protected] >> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ >> > swift-evolution mailing list >> > [email protected] >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
