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

[Антон Жилин]

I have to agree with Never. None is for Optional.none, and it looks like
Void in function signature.
I would argue that Never could not be mistaken as a synonym for Void.

protocol Nothing {}
is exactly how Any could be defined, so it's an opposite entity.
We could define that as a protocol that nothing can confirm to, but
approach with empty enum seems more natural to me, because it does not
require any extra work from the compiler.

- Anton

2016-06-05 23:54 GMT+03:00 T.J. Usiyan <griotspeak at gmail.com>:

> *please* let us not repeat the mostly avoidable
> challenging-to-explain-to-newcomers-and-vetarans-alike situation that we
> had in Obj-C with regard to `nil`.
>
> nil
> Nil
> NULL
> NSNull
> nullptr
> kCFNull
> __DARWIN_NULL
>
> are the representations of 'don't have' that come to mind.
>
>
>
> On Sun, Jun 5, 2016 at 2:39 PM, Charlie Monroe via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160606/cbcd6156/attachment.html>