<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>I could be pedantic and say that "previousInterestingFoo" now relies on the newly bound "foo" on assignment in the while loop keeping it relevant contextually.&nbsp;</div><div><br></div><div>Ultimately, my responsibility as a user of the language is not to try to figure out the inner workings of the grammar or the compiler. It's not where my interests are or should be really.</div><div><br></div><div>My interests are the readability and expressiveness of using the language as I use the language. This is not a problem I have a solution for. But as a user of the language, dropping where and introducing semicolons in a lot of places will lead to much less readable code in my opinion, no matter what you say the compiler or grammar can or cannot do.&nbsp;</div><div><br></div><div>This may seem harsh, but as a user and advocate for the users, it's hard for me to recommend a feature that makes the language less readable just to fix the grammar. Am I suppose to care about the compiler or the grammar? Or is the usability of the language more important to me?</div><div><br></div><div>At the end of the day it's not up to me or the other dissenters, but we can at least voice our (rather strong) opinions and that's okay.&nbsp;</div><div><br></div><div>Compiler/grammar folks may strongly disagree with us but this is why we have community reviews: to bring together all users of all backgrounds to the discussion whether that be in compilers, grammar, teachers, etc.&nbsp;</div><div><br></div><div>Will this push me to stop programming in Swift if approved? No.&nbsp;</div><div><br></div><div>Will it make it a little less enjoyable for me to use? A little.&nbsp;</div><div><br></div><div>Brandon&nbsp;</div><div><br>On May 31, 2016, at 2:52 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div style="white-space:pre-wrap">See, I'd wondered about that early on. But it didn'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 "make sense contextually," 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's a huge no-go.<br><br>Or, you might say, "I don't want to support arbitrary Boolean assertions after let bindings at all!" 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't need to be in a where clause and doesn't make sense contextually.&nbsp;</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.&nbsp;</div><div><br></div><div>This may be why some of us are against the proposal.&nbsp;</div></div><div dir="auto"><div><br></div><div>Brandon&nbsp;</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'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'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 &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.&nbsp;</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.&nbsp;</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.&nbsp;</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 &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'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 &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'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's `&amp;&amp;` doesn't ever produce an optional, so if we'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'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 &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>
</div></blockquote></body></html>