<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="">interestingly enough, it looks like a truly simple task... the grammar has 2 types of BindingKind at that location BK_Let and BK_Var, which means that a single shorthand notation will assume one of the other, which means that if it does assume one, then it better be explicit about it, or alternatively there ought to be 2 shorthands for the 2 binding kinds. i.e. :</div><div class=""><br class=""></div><div class=""><font face="Monaco" class="">if unwrapped_var xxxx {</font></div><div class=""><font face="Monaco" class="">}</font></div><div class=""><br class=""></div><div class="">and </div><div class=""><br class=""></div><div class=""><font face="Monaco" class="">if unwrapped_let xxxx {</font></div><div class=""><font face="Monaco" class="">}</font></div><div class=""><div class=""><br class=""></div><div class="">or perhaps even easier to express as:</div></div><div class=""><br class=""></div><div class=""><div class=""><font face="Monaco" class="">if let! xxxx {</font></div><div class=""><font face="Monaco" class=""> // xxxx is unwrapped LET</font></div><div class=""><font face="Monaco" class="">}</font></div></div><div class=""><font face="Monaco" class=""><br class=""></font></div><div class=""><div class="">and </div></div><div class=""><br class=""></div><div class=""><div class=""><div class=""><font face="Monaco" class="">if var! xxxx {</font></div><div class=""><font face="Monaco" class=""> // xxxx is unwrapped VAR</font></div><div class=""><font face="Monaco" class="">}</font></div></div><div class=""><font face="Monaco" class=""><br class=""></font></div></div><div class=""><div class="">From what I could understand of the compiler, these would seem like localized small scale changes, but unfortunately still entirely out of the scope of 3.0 ( not to mention probably still not bringing the clarity chris identified as main blocker).</div><div class=""><br class=""></div><div class="">Ideas like this one, that are both simple in scope but out of the main focus might still be worth collecting somewhere as a series of “<i class="">if you would like to get familiar with the compiler codebase to try and help at a future date with more serious items, we suggest that you look into finding the least intrusive way to implement any of these features.. we guaranty that there is a simple way to build them</i>”. They might prove a good training ground for would be helpers.</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Apologies for taking your time.</div><div class="">/LM</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On May 17, 2016, at 5:48 PM, Matthew Johnson 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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 17, 2016, at 10:41 AM, Brandon Knope <<a href="mailto:bknope@me.com" class="">bknope@me.com</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="">I always thought a new keyword made more sense here:<div class=""><br class=""></div><div class="">if let <font color="#bb2ca2" face="Menlo" class=""><span style="font-size: 12px;" class="">rebind</span></font> someValue { </div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>//use shadowed unwrapped value in here</div><div class="">}</div><div class=""><br class=""></div><div class="">if let <font color="#bb2ca2" face="Menlo" class=""><span style="font-size: 12px;" class="">bind</span></font> someValue {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>//use shadowed unwrapped value in here</div><div class="">}</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">if let <span style="color: rgb(187, 44, 162); font-family: Menlo; font-size: 12px;" class="">unwrapped </span>someValue {</div><div class=""><br class=""></div><div class="">}</div><div class=""><br class=""></div><div class="">Something along those lines?</div></div></div></blockquote><div class=""><br class=""></div><div class="">I wouldn’t want to see something like this replace the existing `if let` because it doesn’t handle cases where you bind a new name to the result of an expression that returns an optional.</div><div class=""><br class=""></div><div class="">If we did consider something like this it would be simple syntactic sugar for `if let x = x`. Being syntactic sugar for something that is already not too bad means it would need to be as concise as possible. If you want to advocate something like this, maybe consider just `if unwrap`:</div><div class=""><br class=""></div><div class="">if unwrap someValue {</div><div class="">}</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Brandon</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 17, 2016, at 11:31 AM, Patrick Smith 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=""><div class="">Here’s a idea, what if you could use a symbol to denote that you want the same name used?</div><div class=""><br class=""></div><div class="">Here’s an interesting sign from music: <a href="https://en.wikipedia.org/wiki/Repeat_sign" class="">https://en.wikipedia.org/wiki/Repeat_sign</a></div><div class=""><br class=""></div><div class="">Then you can write (one) of these:</div><div class=""><br class=""></div><div class=""><div class="">if let |: = mySomeValue {</div><div class=""> // Use unwrapped</div><div class="">}</div></div><div class=""><br class=""></div><div class=""><div class="">if let mySomeValue = :| {</div><div class=""> // Use unwrapped</div><div class="">}</div></div><div class=""><br class=""></div><div class="">Not sure which one is more clear. Just a totally random idea! I’m not sure about the above symbols, but it would help in other places too from memory to not have to write the same variable name twice.</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 18 May 2016, at 1:18 AM, Matthew Johnson 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 style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On May 17, 2016, at 10:13 AM, Tony Allevato 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=""><div class="">While I've sometimes (early on) wished for a shorter-hand syntax for that construct, I've never been able to think of something that I thought was better. I've gotten to the point where I don't particularly mind it anymore.</div><div class=""><br class=""></div>Regarding the exclamation point specifically, seeing one of those in an expression context says to me "this thing will die horribly if it is nil/throws an error". Using it in this context where that's not the case would probably go against users' expectations.</div></div></blockquote><div class=""><br class=""></div><div class="">Agree. If we are going have syntax similar to pattern matching it should be the same as pattern matching. This would mean using ‘?' rather than ‘!’. However, we already have generalized pattern matching with `if case` for that. This topic has been debated extensively.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">On 17.05.2016 16:51, Johan Jensen wrote:<br class=""> > This was one of the first and most commonly suggested ideas, when the Swift<br class=""> > Evolution mailing list first started.<br class=""> > Chris Lattner sums it up<br class=""> ><br class=""><<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html" rel="noreferrer" target="_blank" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html</a>><br class=""> > in one of those threads:<br class=""> ><br class=""> >> This is commonly requested - the problem is that while it does help<br class=""> > reduce boilerplate, it runs counter to the goal of improving clarity.<br class=""> ><br class=""> > — Johan<br class=""><br class="">Oh, thank you for letting this know.<br class=""><br class="">Well, I totally disagree with Chris. And as soon as there was no 'official'<br class="">proposal and 'official' decision, I'd like to discuss this more.<br class=""><br class="">I saw a lot of code like<br class="">if let mySomeValue = mySomeValue {} in sources and even in books.<br class="">Plus, I really believe that<br class="">if let mySomeValue! {..} is better in any way: readability, less space for<br class="">errors(when you need to repeat the same name) etc<br class=""><br class="">FWIW, I suggest more explicit variant:<br class="">if let value! {...} // with exclamation mark<br class="">In that "old" proposal there was `if let value {...}`, was not so clear.<br class=""><br class="">I can't accept an argument that you can use another name - as usually<br class="">'good' name is already 'crafted' for the instance and you want to use it in<br class="">next code.<br class="">Otherwise, we need a 'best practice' to name optional variables with some<br class="">prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =<br class="">mySomeValueOpt` will have a sense. But as I understand, we don't want to<br class="">use such approach.<br class="">Additionally, when you shadow optional value with same name - you are<br class="">*protecting* yourself from using optional value inside block of unwrapped<br class="">code. IMO it is a good idea.<br class="">And want we or don't want, we already have this practice widely. So I<br class="">believe this(my) proposal will improve the code.<br class=""><br class="">I'd like to get opinion of the community regarding this feature.<br class=""><br class="">On 17.05.2016 16:51, Johan Jensen wrote:<br class="">> This was one of the first and most commonly suggested ideas, when the Swift<br class="">> Evolution mailing list first started.<br class="">> Chris Lattner sums it up<br class="">> <<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html" rel="noreferrer" target="_blank" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003546.html</a>><br class="">> in one of those threads:<br class="">><br class="">>> This is commonly requested - the problem is that while it does help<br class="">> reduce boilerplate, it runs counter to the goal of improving clarity.<br class="">><br class="">> — Johan<br class="">><br class="">> On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution<br class="">> <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class="Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>>> wrote:<br class="">><br class="">> It is common to shadow optional value name with unwrapped value with<br class="">> same name:<br class="">><br class="">> if let someGoodValue = someGoodValue {...}<br class="">><br class="">> What if we'll have a syntax to not repeat the variable name to achieve<br class="">> the same target:<br class="">><br class="">> if let someGoodValue! {...}<br class="">><br class="">> What do you think?<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><span class="Apple-converted-space"> </span><mailto:<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="">><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=""></blockquote></div>_______________________________________________<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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></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>