<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Except some of us have proposed only allowing unwrapped or newly bound variables in the where clause:</div><div><br></div><div>if let y = y where y < z should work</div><div><br></div><div>If let y = y where x < z should be an error because it doesn't need to be in a where clause and doesn't make sense contextually. </div><div><br></div><div>I understand the rationale about why it should be removed...but I find it a little extreme and a little "technical" to the point that some of the personality of the language will be lost...all for the sake being "technically" correct. </div><div><br></div><div>This may be why some of us are against the proposal. </div><div><br></div><div>Brandon </div><div><br></div><div><br>On May 31, 2016, at 1:16 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div>The motivating example is a compelling illustration of a problem with the current grammar. I don't think anyone would disagree that `if let y = y where x < z` is an abomination.<br><br>Now, I see no principled criteria, and none have been proposed here, that would be useful to restrict what can come after `where`. Moreover, I see no contention with the argument that arbitrary Boolean assertions should be possible after a let binding.<br><br>Finally, it is a stated goal of the core team that there shouldn't be multiple 'dialects' of Swift, and that where possible there should be one general solution rather than two options.<br><br>Given these premises, I have to conclude that *if* the motivating issue is to be fixed, we must get rid of `where`.<br><br><br><div class="gmail_quote"><div dir="ltr">On Tue, May 31, 2016 at 11:53 Brandon Knope <<a href="mailto:bknope@me.com">bknope@me.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>To be frank, I just find the proposed syntax to be more ugly and less expressive. </div><div><br></div><div>I just don't find the proposal compelling enough to take away one of the truly "Swifty" syntaxes that I have used and loved. </div><div><br></div><div>If there are other ways to keep "where" while fixing the ambiguity I would rather explore that than require semicolons everywhere. </div><div><br></div><div>I have a feeling that more would object but just aren't perusing the mailing lists. I think we will see much more activity come WWDC</div></div><div dir="auto"><div><br></div><div>Brandon</div></div><div dir="auto"><div><br>On May 31, 2016, at 12:25 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div>In English (and, I'm guessing, many other languages), semicolons are used as a second 'tier' of separators when commas become ambiguous. I'm puzzled that a proposal to bring this longstanding convention to Swift is raising so many objections, even going so far as to prompt alternatives such as this that break clearly useful shorthands.<br><br><div class="gmail_quote"><div dir="ltr">On Tue, May 31, 2016 at 10:44 David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Yet another alternative: would it be possible to disallow commas as variable declaration separators and use them for condition clause separators again:</div><div><br></div><div>let a = 4, b = 8 // becomes illegal and requires to separate them on two lines</div><div><br></div></div><div style="word-wrap:break-word"><div>if a > 4, let c = foo(), let d = bar(), c != d { // now comma is not ambiguous anymore</div><div>}</div></div><div style="word-wrap:break-word"><div><br></div><div>David.</div></div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On 28 May 2016, at 02:30, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br>On May 27, 2016, at 6:26 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>> wrote:<br><br><blockquote type="cite">guard<br>x == 0 && a == b && c == d &&<br>let y = optional, w = optional2, v = optional 3 &&<br>z == 2<br>else { ... }<br><br>Figuring out where to break the first line into expression and into condition (after the `d`) could be very challenging to the compiler.<br></blockquote><br>I'm not sure it is. `let` and `case` are not valid in an expression, so an `&&` followed by `let` or `case` must be joining clauses. On the other side of things, Swift's `&&` doesn't ever produce an optional, so if we're parsing an expression at the top level of an if-let, an `&&` must indicate the end of the clause. An if-case *could* theoretically include an `&&`, but pattern matching against a boolean value seems like a fairly useless thing to do in a context that's specifically intended to test booleans.<br></blockquote><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Let me answer in another way that speaks to my background which isn't in compiler theory: The use of && may produce cognitive overload between the use in Boolean assertions and the use in separating condition clauses.</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">-- E</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">swift-evolution mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="mailto:swift-evolution@swift.org" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">swift-evolution@swift.org</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></blockquote></div>
</div></blockquote></body></html>