<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="">Personally, I wouldn’t like to see any more specialised syntax or compiler voodoo to deal with Optionals. They’re like the Hydra of Swift, though instead of sprouting heads, they sprout new syntax : )<div class=""><br class=""></div><div class="">I’d be all for a more generalised approach, ‘do notation’, ‘for comprehensions’, etc – though that’s not likely to happen in the near term (if ever).<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 11 Dec 2015, at 17:17, Daniel Hooper 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: normal; font-weight: normal; letter-spacing: normal; line-height: 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="">I don't think we should discuss "with" here as that is a separate proposal. I'm trying to draw attention of the approach of Swift generating shadow variables for you when an optional has been proven to be non-null. <br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 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=""><br class=""></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 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="">I didn't say we should remove if/guard let. They would stay.</span><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 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=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 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="">My proposal is to improve readability and reduce verbosity by generating shadow variables after "x != nil" checks. The "with x {}" and "if let x {}" approaches only reduce verbosity, at the additional cost of adding new keywords or syntax to the language, and do not really improve readability. Due to this, generating a shadow variable after "x != nil" is the most straightforward, lowest impact and readable approach.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 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=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 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="">ilya, you bring up a good point about "create shadow->write to original->read shadow" situations being potentially confusing. However "if let x = x" is very common in situations that this isn't an issue: taking a quick look at my code, 50% of all "if/guard let x = x" are on local variables that cannot possibly change out from under the shadow variable. If that could lead to confusion in a given situation, you could fall back on "if let x = maybe_x" to make it clearer that you're operating on a copy of a variable that won't change out from under you. Alternatively, the "if x != nil { x.bla() }" syntax could only be allowed on optionals in the current function scope.</div></div></blockquote></div><br class=""></div></div></body></html>