<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=""><div class="">Here I have a contrived example (I am bad at trying to explain my point -_-):</div><div class=""><br class=""></div>When I see nil, I think of reference types. I.e. Objective-C:<div class=""><br class=""><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(112, 61, 170);" class=""><div style="margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">NSMutableString</span><span style="font-variant-ligatures: no-common-ligatures; color: #000000" class=""> *mutableString = [[</span><span style="font-variant-ligatures: no-common-ligatures" class="">NSMutableString</span><span style="font-variant-ligatures: no-common-ligatures; color: #000000" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #3d1d81" class="">alloc</span><span style="font-variant-ligatures: no-common-ligatures; color: #000000" class="">] </span><span style="font-variant-ligatures: no-common-ligatures; color: #3d1d81" class="">initWithString</span><span style="font-variant-ligatures: no-common-ligatures; color: #000000" class="">:</span><span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">@"123"</span><span style="font-variant-ligatures: no-common-ligatures; color: #000000" class="">];</span></div><div style="margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">__weak</span><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><span style="font-variant-ligatures: no-common-ligatures;" class="">NSMutableString</span><span style="font-variant-ligatures: no-common-ligatures" class=""> *reference = mutableString;</span></div><p style="margin: 0px; line-height: normal; min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><br class="webkit-block-placeholder"></p><div style="margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">reference = mutableString;</span></div><p style="margin: 0px; line-height: normal; min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><br class="webkit-block-placeholder"></p><div style="margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">[reference </span><span style="font-variant-ligatures: no-common-ligatures; color: #3d1d81" class="">appendString</span><span style="font-variant-ligatures: no-common-ligatures" class="">:</span><span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">@"456"</span><span style="font-variant-ligatures: no-common-ligatures" class="">];</span></div><div style="margin: 0px; line-height: normal; min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">mutableString = </span><span style="font-variant-ligatures: no-common-ligatures; color: rgb(187, 44, 162);" class="">nil</span><span style="font-variant-ligatures: no-common-ligatures;" class="">;</span></div></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""><br class=""></span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">//memory is now deallocated because strong references are eliminated</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">// BUT reference is now nil! This is expected with reference types</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; min-height: 13px;" class=""><br class=""></div><p style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; min-height: 13px;" class="">In Objective-C we have to use nil to manage when objects are deallocated. We also have to use __weak to avoid retain cycles etc...</p><div class=""><br class=""></div></div><div class="">This behavior is consistent with other languages with reference semantics.</div><div class=""><br class=""></div><div class="">However, in Swift, optionals are value types as we all know (though they can wrap reference types):</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">var</span><span style="font-variant-ligatures: no-common-ligatures" class=""> number1: </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Int</span><span style="font-variant-ligatures: no-common-ligatures" class="">? = </span><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">nil</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">var</span><span style="font-variant-ligatures: no-common-ligatures" class=""> number2: </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Int</span><span style="font-variant-ligatures: no-common-ligatures" class="">? = </span><span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">number1</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""></span><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(79, 129, 135);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">number1</span><span style="font-variant-ligatures: no-common-ligatures; color: #000000" class=""> == </span><span style="font-variant-ligatures: no-common-ligatures" class="">number2</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""></span><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(79, 129, 135);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">number1</span><span style="font-variant-ligatures: no-common-ligatures; color: #000000" class=""> = </span><span style="font-variant-ligatures: no-common-ligatures; color: #272ad8" class="">3</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(79, 129, 135);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">number2</span><span style="font-variant-ligatures: no-common-ligatures; color: #000000" class=""> == </span><span style="font-variant-ligatures: no-common-ligatures" class="">number1 // FALSE. This behavior is obviously different from Objective-C and we expect that knowing that it’s a value type</span></div></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(79, 129, 135);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(79, 129, 135);" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class="">On first look, it looks like reference semantics because you see <b class="">nil</b> and remember it from other languages. OR you learn this behavior in Swift and expect it to work the same in other languages. Either way the behavior isn’t exactly consistent between all languages. Even nil in Objective-C is different than most languages because you are allowed to send messages to it.</div><div style="margin: 0px; line-height: normal;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class="">As far as I know, setting:</div><div style="margin: 0px; line-height: normal;" class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(79, 129, 135);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">number1</span><span style="font-variant-ligatures: no-common-ligatures; color: #000000" class=""> = </span><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">nil</span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class=""><br class=""></span></div></div><div style="margin: 0px; line-height: normal;" class="">does not deallocate <span style="color: rgb(79, 129, 135); font-family: Menlo; font-size: 11px;" class="">number1</span>. It is still an optional with enough space to wrap an Int that happens to just be set to .none currently.</div><div style="margin: 0px; line-height: normal;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class=""><b class="">It looks like you are deallocating something if that is the behavior you expect from other languages upon seeing nil.</b></div><div style="margin: 0px; line-height: normal;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class="">nil can have similar behaviors in both languages, but they can also have very dissimilar behaviors too.</div><div style="margin: 0px; line-height: normal;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class="">My main point comes down to: <b class="">nil</b> makes it look like a pointer and thus makes you see it as a reference type at first glance until you completely retrain yourself. This is not how nil works with values in Swift and I think some might find that surprising down the road when:</div><div style="margin: 0px; line-height: normal;" class="">A) They learn Swift first and move to another language and see a different behavior than they are use to</div><div style="margin: 0px; line-height: normal;" class="">B) They come from another language and associate seeing nil with the type being a reference and being surprised</div><div style="margin: 0px; line-height: normal;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class="">or C…you just have to remember the differences.</div><div style="margin: 0px; line-height: normal;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class="">I probably made my point even worse but I can only try!</div><div style="margin: 0px; line-height: normal;" class="">Brandon</div><div style="margin: 0px; line-height: normal;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 8, 2016, at 5:37 PM, Sean Heber <<a href="mailto:sean@fifthace.com" class="">sean@fifthace.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">When isn’t it?<br class=""><br class="">l8r<br class="">Sean<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Jun 8, 2016, at 4:22 PM, Brandon Knope <<a href="mailto:bknope@me.com" class="">bknope@me.com</a>> wrote:<br class=""><br class="">Yes it is the same keyword, but is it the same behavior from other languages?<br class=""><br class="">Brandon<br class=""><br class=""><blockquote type="cite" class="">On Jun 8, 2016, at 5:20 PM, Saagar Jha <<a href="mailto:saagarjha28@gmail.com" class="">saagarjha28@gmail.com</a>> wrote:<br class=""><br class="">I think we also need to consider newbies coming from other languages. “nil” being a holdover makes it easier to understand what it means, having a “.none”/“none” duality makes it both seem inconsistent as well as dredge up language implementation details-now you have to explain that Optionals are actually enums internally. Using nil doesn’t lead to this kind of scenario, and they already (mostly) know what it means from other languages.<br class=""><br class="">On Wed, Jun 8, 2016 at 2:13 PM Sean Heber via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">If there’s both “.none” and “none”, then I think that’d be more confusing *because of* the naming consistency, IMO. I’d look at that as a newbie and wonder why in the world this word sometimes has a dot and sometimes doesn’t.<br class=""><br class="">If enum cases could be referred to without the leading “.” then perhaps I could get behind this because “none” wouldn’t even need to be a keyword at all in that case, but there are probably difficult ambiguities down that road.<br class=""><br class="">l8r<br class="">Sean<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Jun 8, 2016, at 4:04 PM, Brandon Knope <<a href="mailto:bknope@me.com" class="">bknope@me.com</a>> wrote:<br class=""><br class="">1. People will find .none ugly which is why I think it could be replaced by a none keyword. It is awkward<br class="">2. none is more descriptive than nil in this case. The case is named none (consistency!) and nil is a holdover from other languages<br class=""><br class="">I understand how nil works in the context of other languages. But looking at Optional:<br class="">public enum Optional<Wrapped> : NilLiteralConvertible {<br class=""><br class=""> /// The absence of a value.<br class=""> ///<br class=""> /// In code, the absence of a value is typically written using the `nil`<br class=""> /// literal rather than the explicit `.none` enumeration case.<br class=""> case none<br class=""><br class=""> /// The presence of a value, stored as `Wrapped`.<br class=""> case some(Wrapped)<br class="">}<br class=""><br class=""><br class="">These are not pointers and they sure look like one when you assign nil to an optional<br class=""><br class="">B<br class=""><br class="">Why would nil be chosen to represent the none case in the absence of other languages?<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Jun 8, 2016, at 4:55 PM, Sean Heber <<a href="mailto:sean@fifthace.com" class="">sean@fifthace.com</a>> wrote:<br class=""><br class="">If you add a new keyword called “none” without the period, but keep allowing “.none” to work because Optional is really an enum… then I don’t really see what has been gained here at all - you’re basically back to nil/.none => 2 ways to say the same thing!<br class=""><br class="">l8r<br class="">Sean<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Jun 8, 2016, at 3:52 PM, Brandon Knope via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">.none or a more appropriate keyword like “none” (imo)<br class=""><br class="">Brandon<br class=""><br class=""><blockquote type="cite" class="">On Jun 8, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br 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?<br class=""><br class=""><br class="">On Wed, Jun 8, 2016 at 3:41 PM, Антон Жилин <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">(No joking)<br class="">Points:<br class=""><br class="">1. When nil was added to the language, we could not infer enumeration type:<br class="">if x != Optional.none { ... }<br class=""><br class="">Now it looks like this:<br class="">if x != .none { ... }<br class=""><br class="">If at this point we had a proposal to add nil as a replacement for .none, would we accept it?<br class=""><br class="">2. nil is very generic, it only approximately allows to express the intentions.<br 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.<br class=""><br class="">3. Too many "empty" things: .none, nil; NSNull, Void, NoReturn types.<br class=""><br class="">4. There should be a single consistent terminology: no value in Swift equals none.<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="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></blockquote><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="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></blockquote><br class=""></blockquote><br class=""></blockquote><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="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class="">-- <br class="">-Saagar Jha<br class=""></blockquote><br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></div></div></body></html>