<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 7, 2017, at 11:22 PM, Howard Lovatt 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="">Not a big deal either way, but I prefer the 2nd (nil) form and therefore would like to see the 1st form go. It would make Swift more consistent, consider:<div class=""><br class=""></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class="">let o: Int? // Looks like nil is assigned.<br class="">if someTest {<br class=""> o = 1 // Why isn't this an error? (OK I know why - but it looks odd.)<br class="">} else {<br class=""> o = nil<br class="">}<br class=""><br class=""><br class=""></blockquote>Whilst the above works it is weird because if you are aware that o: Int? normally assigns nil then the above looks like o, which is a let, is assigned to twice. If you do the equivalent of the above for a non-optional it is an error.</div></div></blockquote><div><br class=""></div>The default initialization behavior is specifically not enabled for let bindings. Compare:</div><div><br class=""></div><div>let x: Int?<br class="">print(x as Any) // error: constant 'x' used before being initialized<br class=""><br class="">var y: Int?<br class="">print(y as Any)</div><div><br class=""></div><div>So your example is perfectly consistent, because you’re only initializing ‘o’ once (along each control flow path).</div><div><br class=""></div><div>Slava</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature" data-smartmail="gmail_signature"> -- Howard.<br class=""></div></div>
<br class=""><div class="gmail_quote">On 8 November 2017 at 07:54, Adrian Zubarev 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"><div style="word-wrap:break-word" class=""><div id="m_-7996343717438270161bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">Same here, but I wouldn’t care much if it were gone.</div><div class=""><div class="h5"> <br class=""> <div id="m_-7996343717438270161bloop_sign_1510087959354830080" class="m_-7996343717438270161bloop_sign"></div> <br class=""><p class="m_-7996343717438270161airmail_on">Am 7. November 2017 um 21:40:56, David Hart via swift-evolution (<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="m_-7996343717438270161clean_bq"><span class=""><div class=""><div class=""></div><div class="">Yeah, I use the first form constantly.<br class=""><br class="">> On 6 Nov 2017, at 23:33, Slava Pestov via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">> <br class="">> Hi all,<br class="">> <br class="">> Right now, the following two declarations are equivalent:<br class="">> <br class="">> struct S {<br class="">> var x: Int?<br class="">> }<br class="">> <br class="">> struct S {<br class="">> var x: Int? = nil<br class="">> }<br class="">> <br class="">> That is, mutable bindings of sugared optional type (but not Optional<T>!) always have a default value of ‘nil’. This feature increases the surface area of the language for no good reason, and I would like to deprecate it in -swift-version 5 with a short proposal. Does anyone feel strongly about giving it up? I suspect most Swift users don’t even know it exists.<br class="">> <br class="">> Slava<br class="">> ______________________________<wbr 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" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class=""><br class="">______________________________<wbr 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" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class=""></div></div></span></blockquote></div></div></div><br class="">______________________________<wbr 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/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
<br class=""></blockquote></div><br class=""></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=""></body></html>