<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Ceylon demonstrates other uses for the bottom type than just marking @noreturn methods, e.g. (mixing Ceylon and Swift syntax freely here)<div class=""><br class=""></div><div class="">class Iterable<Element, Absent = Null> {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var last: Element | Absent<span class="Apple-tab-span" style="white-space:pre"> </span>// remember that optionals in Ceylon are modeled as union type T | Null</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>...</div><div class="">}</div><div class=""><br class=""></div><div class="">Iterable<String> // a possibly empty iterable where last: Element | Null, i.e. last: Element?</div><div class="">Iterable<String, Never> // a non-empty iterable where last: Element | Never, i.e. last: Element</div><div class=""><br class=""></div><div class="">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.</div><div class="">This is very elegant IMHO.</div><div class=""><br class=""></div><div class="">-Thorsten</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 06.06.2016 um 19:46 schrieb Jacob Bandes-Storch via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">What about `PreconditionFailure`? If you obtain an instance of this type, it means a precondition has failed.<div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><div class="">Jacob<br class=""></div></div></div></div>
<br class=""><div class="gmail_quote">On Mon, Jun 6, 2016 at 9:48 AM, Joe Groff via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">`Never` seems reasonable to me too. I'll add that to the proposal as an alternative.<br class="">
<br class="">
-Joe<br class="">
<div class="HOEnZb"><div class="h5"><br class="">
> On Jun 5, 2016, at 11:37 AM, T.J. Usiyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> I vote for Bottom or Never. None does not convey "this should not occur or be evaluated".<br class="">
><br class="">
> On Sun, Jun 5, 2016 at 2:26 PM, Антон Жилин <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
> The following names were suggested: NoReturn, Bottom, None, Never.<br class="">
> I would pick None, because it looks like opposite to Any and fits nicely in generic types.<br class="">
><br class="">
> I would prefer the type to be simple, and be implemented as a case-less enum (not a bottom value, as in Haskell).<br class="">
><br class="">
> None should be a usual enum, with no compiler magic except that functions returning None are equivalent to current @noreturn.<br class="">
><br class="">
> Example 1.<br class="">
> let x: None?<br class="">
> // ...<br class="">
> let y = x!<br class="">
><br class="">
> 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.<br class="">
> We could prove that it is always true in this case, but compiler must be stupid about this.<br class="">
><br class="">
> Example 2.<br class="">
> Compiler should allow including None in structures. Error will show up in constructor, when we will not be able to initialize the field.<br class="">
><br class="">
> Example 3.<br class="">
> None in an enum case makes that case never appear in values of such a type. But compiler can not know about that.<br class="">
><br class="">
> - Anton<br class="">
><br class="">
> _______________________________________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
><br class="">
><br class="">
> _______________________________________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>