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

[Xiaodi Wu]

On Mon, Jun 6, 2016 at 10:39 AM, Charlie Monroe via swift-evolution <
swift-evolution at swift.org> 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 <
> 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>:
>>
>> > +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>:
>> >>>
>> >>> 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>:
>> >>>>
>> >>>> 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> 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
>> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >>>>
>> >>>> _______________________________________________
>> >>>> swift-evolution mailing list
>> >>>> swift-evolution at swift.org
>> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >>> _______________________________________________
>> >>> swift-evolution mailing list
>> >>> swift-evolution at swift.org
>> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >> _______________________________________________
>> >> swift-evolution mailing list
>> >> swift-evolution at swift.org
>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160606/fa469d5e/attachment.html>