[swift-evolution] [Draft] Change @noreturn to unconstructible return type
griotspeak at gmail.com
Sun Jun 5 15:54:00 CDT 2016
*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`.
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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution