<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="">In my other thread where this came up, my support is:<div class="">1. Removing NilLiteralConvertible conformance from Optional (apparently other people use this protocol?)</div><div class="">2. Introducing a new keyword that is sugar for .none</div><div class=""><br class=""></div><div class="">Would I like to remove nil and NilLiteralConvertible? Perhaps, but it seems that some people use them for other things and I would hate to take it away from them. </div><div class=""><br class=""></div><div class="">My concerns come down to this:</div><div class="">- It looks like a pointer</div><div class="">- People learning Swift as their first language will go to other languages and expect “nil” to be safe. Swift seems to be mostly alone here: nil is safe whereas in most languages it is not safe to dereference a nil pointer</div><div class="">- It is not consistent with the Optional enum naming</div><div class="">- It is not as descriptive or expressive</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Brandon<br class=""><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Jun 8, 2016, at 4:59 PM, Brandon Knope via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Is it really an implementation detail? It is very leaky if it is one because it is highly exposed to everyone.<div class=""><br class=""></div><div class="">Regardless of whether or not it is an implementation detail, nil does not adequately describe the “none” case it is trying to represent in my opinion<br class=""><div class=""><br class=""></div><div class="">B</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 8, 2016, at 4:56 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 8, 2016 at 3:52 PM, Brandon Knope <span dir="ltr" class=""><<a href="mailto:bknope@me.com" target="_blank" class="">bknope@me.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">.none or a more appropriate keyword like “none” (imo)<span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div></font></span></div></blockquote><div class=""><br class=""></div><div class="">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 class=""> </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" class=""><span class="HOEnZb"><font color="#888888" class=""><div class=""></div><div class="">Brandon</div></font></span><div class=""><div class="h5"><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">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 class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин <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"><div dir="ltr" class="">(No joking)<div class=""><div class="">Points:<div class=""><br class=""></div><div class="">1. When nil was added to the language, we could not infer enumeration type:</div><div class="">if x != Optional.none { ... }</div><div class=""><br class=""></div><div class="">Now it looks like this:</div><div class="">if x != .none { ... }</div><div class=""><br class=""></div><div class="">If at this point we had a proposal to add nil as a replacement for .none, would we accept it?</div><div class=""><br class=""></div><div class="">2. nil is very generic, it only approximately allows to express the intentions.</div><div class="">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 class=""><br class=""></div><div class="">3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.</div><div class=""><br class=""></div><div class="">4. There should be a single consistent terminology: no value in Swift equals none.</div><div class=""><br class=""></div><div class="">- Anton</div></div></div></div>
<br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" 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=""></blockquote></div><br class=""></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></div></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></div></body></html>