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

[Thorsten Seitz]

Ceylon demonstrates other uses for the bottom type than just marking @noreturn methods, e.g. (mixing Ceylon and Swift syntax freely here)

class Iterable<Element, Absent = Null> {
	var last: Element | Absent	// remember that optionals in Ceylon are modeled as union type T | Null
	...
}

Iterable<String> // a possibly empty iterable where last: Element | Null, i.e. last: Element?
Iterable<String, Never> // a non-empty iterable where last: Element | Never, i.e. last: Element

This achieves type safety for `last` (and a couple of other methods not shown here) with respect to the property of an iterable statically known to be non-empty.
This is very elegant IMHO.

-Thorsten


> Am 06.06.2016 um 19:46 schrieb Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org>:
> 
> What about `PreconditionFailure`? If you obtain an instance of this type, it means a precondition has failed.
> 
> Jacob
> 
> On Mon, Jun 6, 2016 at 9:48 AM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> `Never` seems reasonable to me too. I'll add that to the proposal as an alternative.
> 
> -Joe
> 
> > On Jun 5, 2016, at 11:37 AM, T.J. Usiyan via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >
> > I vote for Bottom or Never. None does not convey "this should not occur or be evaluated".
> >
> > On Sun, Jun 5, 2016 at 2:26 PM, Антон Жилин <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/ab3a4d38/attachment.html>