<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="">I don't see a reason to rename or remove the `nil` literal.</div><div class=""><br class=""></div><div class="">But I can come up with a concrete reason to deprecate NilLiteralConvertible: The language has made Optional a very specific thing with `if let` syntax, implicit wrapping, and optional chaining to name a few. But the second most common way (I guess) to create an Optional—by using the `nil` literal—isn't actually guaranteed to create an Optional.</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""> let condition: Bool</font></div><div class=""><font face="Menlo" class=""> let x = condition ? 1 : nil</font></div><div class=""><font face="Menlo" class=""> // <b class="">error:</b> result values in '? :' expression have mismatching types 'Int' and '_'</font></div><div class=""><br class=""></div><div class="">An expression like the above doesn't compile because the compiler can't tell what type `nil` should initialise. (Currently, at least Optional<Int> and ImplicitlyUnwrappedOptional<Int> seem possible, but with NilLiteralConvertible, something like a conforming MyJSON could be as well!) This, I think, can be confusing to new users. And life would be simpler if `nil` always stood for `Optional.none`, which would then infer the associated Wrapped type respectfully.</div><div class=""><br class=""></div><div class="">So no, I don't support this idea but I think we should sunset NilLiteralConvertible.</div><div class=""><br class=""></div><div class="">— Pyry</div><div class=""><br class=""></div><div class="">PS. Besides, the above statement will compile with any of the following edits:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""> let x = condition ? 1 : <b class="">Optional.none</b></font></div><div class=""><font face="Menlo" class=""> let x = condition ? 1 : nil <b class="">as Optional</b></font></div><div class=""><font face="Menlo" class=""> let x = condition ? 1 : <b class="">Optional()</b></font></div><div class=""><font face="Menlo" class=""> let x = condition ? 1 <b class="">as Optional</b> : nil</font></div><div class=""><div class=""><font face="Menlo" class=""> let x = condition ? 1 <b class="">as Int?</b> : nil</font></div></div><div class=""><div class=""><font face="Menlo" class=""> let x = condition ? <b class="">Optional(1)</b> : nil</font></div></div><div class=""><div class=""><font face="Menlo" class=""> let x: <b class="">Int?</b> = condition ? 1 : nil</font></div></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On 08 Jun 2016, at 23:41, Антон Жилин 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=""><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="">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="">
<br class=""></body></html>