<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 8, 2016 at 3:52 PM, Brandon Knope <span dir="ltr"><<a href="mailto:bknope@me.com" target="_blank">bknope@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">.none or a more appropriate keyword like “none” (imo)<span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div></blockquote><div><br></div><div>My point is that `.none` exposes the underlying enum. The premise here is that the enum is an implementation detail. You'll notice that, currently, significant sugar and magic is devoted to allowing you to work with optionals without ever writing `.some` or `none`. For example, `if let x = ...` and friends allow you to avoid writing `if case .some(let x) = ...`, while you can write `return x` instead of `return .some(x)`. This was, IIUC, a deliberate choice to allow progressive disclosure of the language to learners. Renaming `nil` to `none` is a different proposal from Anton is proposing here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class="HOEnZb"><font color="#888888"><div></div><div>Brandon</div></font></span><div><div class="h5"><div><br><div><blockquote type="cite"><div>On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr">It's been pointed out before that Optional being an enum type is treated like an implementation detail. Currently, it is possible to teach the concept of Optional without introducing enum types or generics. How would you do so after elimination of nil?<div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">(No joking)<div><div>Points:<div><br></div><div>1. When nil was added to the language, we could not infer enumeration type:</div><div>if x != Optional.none { ... }</div><div><br></div><div>Now it looks like this:</div><div>if x != .none { ... }</div><div><br></div><div>If at this point we had a proposal to add nil as a replacement for .none, would we accept it?</div><div><br></div><div>2. nil is very generic, it only approximately allows to express the intentions.</div><div>In case of Optional, .none is clearer. In case of JSON processing, .null is clearer. In case of a semantically nullable struct, NilLiteralConvertible usually goes to default constructor.</div><div><br></div><div>3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.</div><div><br></div><div>4. There should be a single consistent terminology: no value in Swift equals none.</div><div><br></div><div>- Anton</div></div></div></div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></div></div></blockquote></div><br></div></div>