<div style="white-space:pre-wrap">See, I&#39;d wondered about that early on. But it didn&#39;t sound like this was a restriction that could be formalized straightforwardly in the grammar.<br><br>Even if it could, it is too restrictive. Consider:<br><br>```<br>var previousInterestingFoo = 0<br><br>while let foo = sequence.next() where previousInterestingFoo &lt; 42 {<br>  // determine if foo is interesting<br>  // ...<br>  if interesting {<br>    previousInterestingFoo = foo<br>  }<br>}<br>```<br><br>If we enforce a rule like you propose, then this example above, which arguably does &quot;make sense contextually,&quot; would no longer be acceptable.<br><br>Switching gears to a different argument: this proposal aims (among other things) to provide a way to make arbitrary Boolean assertions after a let binding in situations where the use of `where` is currently required but reads absurdly. Whatever alternative grammar is proposed for these arbitrary Boolean assertions will, by construction, *always* be useful regardless of the variables used in the assertion.<br><br>Thus, if we keep `where` and enforce your proposed rule, you end up with two ways to express the same thing; `where` clauses would permit a strict subset of assertions that can be expressed using the alternative syntax. And, the compiler is conscripted to be an opinionated arbiter of style. That&#39;s a huge no-go.<br><br>Or, you might say, &quot;I don&#39;t want to support arbitrary Boolean assertions after let bindings at all!&quot; Well then, if we try to enforce your proposed rule, then a user who wants to write `let y = y where x &lt; z` would be driven to this gem of a workaround: `let y = y where (y == y &amp;&amp; x &lt; z)`.<br><br>These lines of reasoning are what have compelled me to conclude that `where` might not be salvageable.<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, May 31, 2016 at 13:04 Brandon Knope &lt;<a href="mailto:bknope@me.com">bknope@me.com</a>&gt; 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>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 &lt; z should work</div><div><br></div><div>If let y = y where x &lt; z should be an error because it doesn&#39;t need to be in a where clause and doesn&#39;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 &quot;technical&quot; to the point that some of the personality of the language will be lost...all for the sake being &quot;technically&quot; correct. </div><div><br></div><div>This may be why some of us are against the proposal. </div></div><div dir="auto"><div><br></div><div>Brandon </div></div><div dir="auto"><div><br></div><div><br>On May 31, 2016, at 1:16 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>The motivating example is a compelling illustration of a problem with the current grammar. I don&#39;t think anyone would disagree that `if let y = y where x &lt; 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&#39;t be multiple &#39;dialects&#39; 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 &lt;<a href="mailto:bknope@me.com" target="_blank">bknope@me.com</a>&gt; 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&#39;t find the proposal compelling enough to take away one of the truly &quot;Swifty&quot; syntaxes that I have used and loved. </div><div><br></div><div>If there are other ways to keep &quot;where&quot; 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&#39;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 &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>In English (and, I&#39;m guessing, many other languages), semicolons are used as a second &#39;tier&#39; of separators when commas become ambiguous. I&#39;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 &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; 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 &gt; 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 &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; 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 &lt;<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>&gt; wrote:<br><br><blockquote type="cite">guard<br>x == 0 &amp;&amp; a == b &amp;&amp; c == d &amp;&amp;<br>let y = optional, w = optional2, v = optional 3 &amp;&amp;<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&#39;m not sure it is. `let` and `case` are not valid in an expression, so an `&amp;&amp;` followed by `let` or `case` must be joining clauses. On the other side of things, Swift&#39;s `&amp;&amp;` doesn&#39;t ever produce an optional, so if we&#39;re parsing an expression at the top level of an if-let, an `&amp;&amp;` must indicate the end of the clause. An if-case *could* theoretically include an `&amp;&amp;`, but pattern matching against a boolean value seems like a fairly useless thing to do in a context that&#39;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&#39;t in compiler theory: The use of &amp;&amp; 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></div></blockquote></div>