Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> Am 01.06.2016 um 03:47 schrieb Xiaodi Wu via swift-evolution > : > > > > It does occur to me that there is one more option. I don't know that I like > it, but it's an option no one has put forward before: recite the opening > keyword when beginning a new boolean

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> Le 31 mai 2016 à 21:47, Xiaodi Wu via swift-evolution > a écrit : > > Revisiting this conversation, it seems that most of the design space has been > thoroughly explored. I think all suggestions presented so far boil down to > these: > > Q: How is an arbitrary

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

+1 I think that it is an improvement overall and the work for consistency is appreciated. On Sat, Jun 4, 2016 at 10:03 PM, Greg Titus via swift-evolution < swift-evolution@swift.org> wrote: > > I think that Jon has exactly described my view on this proposal. Thanks, > Jon. > > -1. > > -- Greg

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

I think that Jon has exactly described my view on this proposal. Thanks, Jon. -1. -- Greg > On Jun 4, 2016, at 12:17 AM, Jon Shier via swift-evolution > wrote: > > The suitability of “where” as the keyword in these clauses is a > completely separate

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

The suitability of “where” as the keyword in these clauses is a completely separate issue. Frankly, it just comes down to English not having a good, single word to describe an if-and-only-if relationship. So “where" was chosen (some explanation from the original designers has been

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

It is of course true that all parts of a conditional statement have something in common with each other, namely that they are part of the same conditional statement. A problem definitely exists with the current syntax, which is that the de minimis semantic relationship you are showing is not the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> To fix any confusion between these I'd rather change the syntax of the > conditional let binding to something like `let x ?= x` or similar (which > has been proposed quite a few times on this list already). FWIW, I also think `if let one = two` is not descriptive enough about what is going

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> Am 01.06.2016 um 03:47 schrieb Xiaodi Wu via swift-evolution > : > > Revisiting this conversation, it seems that most of the design space has been > thoroughly explored. I think all suggestions presented so far boil down to > these: > > Q: How is an arbitrary

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> Am 01.06.2016 um 00:26 schrieb Paul Cantrell via swift-evolution > : > > I certainly am warm to that myself, although I’m also sympathetic to what > Chris wrote about the inconsistency it introduces: > > let x = optionalX!, y = optionalY! // Works! >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> Am 31.05.2016 um 23:01 schrieb Haravikk via swift-evolution > : > > >> On 31 May 2016, at 18:57, Erica Sadun via swift-evolution >> wrote: >> >> * Should `where` clauses be allowed where the contents of the where clause >> have no

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

I’ve always had a funny feeling about the `where` keyword in `if` statements. It feels like it adds structure, but it’s not the most flexible of keywords. I sometimes find myself writing to match the structure it wants rather than the other way around. I rather like this proposal. What if

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Apologies for going off that tangent earlier. > On May 31, 2016, at 7:47 PM, Xiaodi Wu via swift-evolution > wrote: > > Revisiting this conversation, it seems that most of the design space has been > thoroughly explored. I think all suggestions presented so far boil

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On 1 Jun 2016, at 02:47, Xiaodi Wu via swift-evolution > wrote: > > Q: How is an arbitrary boolean assertion introduced after `if let`? > > Option 1 (present scenario)--using `where` > Advantages: expressive when it means exactly the right thing > Drawbacks: makes

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Revisiting this conversation, it seems that most of the design space has been thoroughly explored. I think all suggestions presented so far boil down to these: Q: How is an arbitrary boolean assertion introduced after `if let`? Option 1 (present scenario)--using `where` Advantages: expressive

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

>> On May 27, 2016, at 5:30 PM, Erica Sadun via swift-evolution >> wrote: >> >> >>> On May 27, 2016, at 6:26 PM, Brent Royal-Gordon >>> wrote: >>> guard x == 0 && a == b && c == d && let y = optional, w = optional2, v =

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

I certainly am warm to that myself, although I’m also sympathetic to what Chris wrote about the inconsistency it introduces: let x = optionalX!, y = optionalY! // Works! doStuff(x, y) if let x = optionalX, y = optionalY { // Doesn’t work. Confusion! doStuff(x, y) }

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Exactly what I feel about this. I am prepared to go as far as disallowing: let x = optionalX, y = optionalY syntax to free up comma for use instead of semicolon. Then the above becomes: let x = optionalX, let y = optionalY In this case we will keep the comma at the end of the line as well.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On Tue, May 31, 2016 at 3:43 PM, Brandon Knope wrote: > Why would that argue for the removal of where > > if let y = y where y != 5 && x < z > > I would still prefer: > if let y = y where y != 5, x < z, let z = someOptional where z == 10 > > To me, where still has a place. And

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Except I disagree. It might seem like a stylistic flourish, but it can be more expressive in informing the reader that the variable after the where clause was recently introduced somewhere in the preceding clause. Without it, you'd have to scan the entire conditional clause and around the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Why would that argue for the removal of where if let y = y where y != 5 && x < z I would still prefer: if let y = y where y != 5, x < z, let z = someOptional where z == 10 To me, where still has a place. And that place is saying "hey this is a recently introduced or shadowed variable, so don't

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On Tue, May 31, 2016 at 3:16 PM, Brandon Knope wrote: > What is wrong with: > > if let x = x where x > 10, y != 5, let z = z where z != x > > Just as a contrived example? > Because any grammar that permits what you propose would necessarily permit: ``` if let x = x, x > 10, y !=

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On Tue, May 31, 2016 at 3:16 PM, Brandon Knope wrote: > And why couldn't we propose that it should? > And that is this proposal; the options considered for the spelling are comma, semicolon, and `&&`. Now we circle back to my earlier point. The introduction of any of these would

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

And why couldn't we propose that it should? Brandon > On May 31, 2016, at 4:14 PM, Xiaodi Wu wrote: > >> On Tue, May 31, 2016 at 3:08 PM, Brandon Knope wrote: >> What is wrong with: >> >> if let y = y && x < z >> >> They are, after all, independent from

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

What is wrong with: if let x = x where x > 10, y != 5, let z = z where z != x Just as a contrived example? Brandon > On May 31, 2016, at 4:03 PM, Xiaodi Wu wrote: > >> On Tue, May 31, 2016 at 2:59 PM, Brandon Knope wrote: >> Except "b" is the main focus

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On Tue, May 31, 2016 at 3:08 PM, Brandon Knope wrote: > What is wrong with: > > if let y = y && x < z > > They are, after all, independent from each other. > That won't compile. Brandon > > On May 31, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution < >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 31, 2016, at 1:59 PM, Brandon Knope wrote: > > Except "b" is the main focus of the where clause and b was just in the > preceding if condition. > > I feel like we are trying to find ways to break the current where clause even > though we've enjoyed it for almost a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

The y == y I presume is to get around this requirement by reintroducing a variable in the previous part of the conditional to be able to refer to other variables. x > z isn't allowed, but y == y && x > z would be because it's using y. I'm not convinced anyone would do this when they could

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

What is wrong with: if let y = y && x < z They are, after all, independent from each other. Brandon > On May 31, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Tue, May 31, 2016 at 2:51 PM, Christopher Kornher via swift-evolution >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On Tue, May 31, 2016 at 2:59 PM, Brandon Knope wrote: > Except "b" is the main focus of the where clause and b was just in the > preceding if condition. > > I feel like we are trying to find ways to break the current where clause > even though we've enjoyed it for almost a year

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On Tue, May 31, 2016 at 2:51 PM, Christopher Kornher via swift-evolution < swift-evolution@swift.org> wrote: > > On May 31, 2016, at 1:47 PM, Xiaodi Wu wrote: > > > > On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution < > swift-evolution@swift.org>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Except "b" is the main focus of the where clause and b was just in the preceding if condition. I feel like we are trying to find ways to break the current where clause even though we've enjoyed it for almost a year now. I had no idea it was problematic and restrictive. I thought it made its

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 31, 2016, at 1:47 PM, Xiaodi Wu wrote: > > > > On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution > > wrote: >> >> Not allowed: >> … >> let a = a >> let b = b where b > 10 && a >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution < swift-evolution@swift.org> wrote: > >> Not allowed: >> … >> let a = a >> let b = b where b > 10 && a > 5 >> > > Why would this not be allowed by your rule? You're making use of `b` in > your where clause. As I demonstrated

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> > Not allowed: > … > let a = a > let b = b where b > 10 && a > 5 > > Why would this not be allowed by your rule? You're making use of `b` in your > where clause. As I demonstrated above, essentially any assertion can be > rewritten to work around your rule. In general: It is not allowed

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 31, 2016, at 1:00 PM, Erica Sadun via swift-evolution > wrote: > > >> On May 31, 2016, at 12:52 PM, Xiaodi Wu wrote: >> These lines of reasoning are what have compelled me to conclude that `where` >> might not be salvageable. > > To

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

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. Ultimately, my responsibility as a user of the language is not to try to figure out the inner workings of the grammar or the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 31, 2016, at 12:52 PM, Xiaodi Wu wrote: > These lines of reasoning are what have compelled me to conclude that `where` > might not be salvageable. To which, I'd add: `where` suggests there's a subordinate and semantic relationship between the primary condition

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

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. Even if it could, it is too restrictive. Consider: ``` var previousInterestingFoo = 0 while let foo = sequence.next() where previousInterestingFoo <

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> What I'm hearing is that at least some developers would like to retain > where clauses in case conditions and optional binding conditions but still > allow the more controllable logic introduced by differentiating condition > types with semicolons or newlines. Is that a fair summary? I believe

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Except some of us have proposed only allowing unwrapped or newly bound variables in the where clause: if let y = y where y < z should work 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. I understand the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 31, 2016, at 11:16 AM, Xiaodi Wu wrote: > > 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. > > Now, I see no principled

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

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. Now, I see no principled criteria, and none have been proposed here, that would be useful to restrict what can come

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

To be frank, I just find the proposed syntax to be more ugly and less expressive. I just don't find the proposal compelling enough to take away one of the truly "Swifty" syntaxes that I have used and loved. If there are other ways to keep "where" while fixing the ambiguity I would rather

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Yet another alternative: would it be possible to disallow commas as variable declaration separators and use them for condition clause separators again: let a = 4, b = 8 // becomes illegal and requires to separate them on two lines if a > 4, let c = foo(), let d = bar(), c != d { // now comma is

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Like some others on this list I prefer the `where` because it stands out and therefore increases readability by visually separating semantically different clauses. -Thorsten > Am 31.05.2016 um 07:10 schrieb Xiaodi Wu : > > Of course, an alternative is to eliminate

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Of course, an alternative is to eliminate `where` for all uses of `case` as well. On Mon, May 30, 2016 at 11:55 PM Thorsten Seitz via swift-evolution < swift-evolution@swift.org> wrote: > > > Am 29.05.2016 um 17:11 schrieb Thorsten Seitz via swift-evolution < > swift-evolution@swift.org>: > > > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> Am 29.05.2016 um 17:11 schrieb Thorsten Seitz via swift-evolution > : > > >> Am 28.05.2016 um 22:35 schrieb Chris Lattner : >> >> >>> On May 28, 2016, at 12:07 PM, Thorsten Seitz wrote: >>> >>> What about requiring

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On May 31, 2016, at 12:54 AM, Brent Royal-Gordon via swift-evolution wrote: >> Thanks everyone. FYI, Erica and I discussed it offlist and agreed to amend >> the proposal: now you can use semicolons or a newline to separate clauses of >> different types. > > This

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 30, 2016, at 10:54 PM, Erica Sadun via swift-evolution > wrote: > > >>> On May 28, 2016, at 4:48 PM, Chris Lattner via swift-evolution >>> wrote: >>> >>> >>> On May 27, 2016, at 12:11 PM, Joe Groff wrote:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> Thanks everyone. FYI, Erica and I discussed it offlist and agreed to amend > the proposal: now you can use semicolons or a newline to separate clauses of > different types. This change does not alter my concern about the overloading of the semicolon as a statement separator, and in fact, it

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 28, 2016, at 4:48 PM, Chris Lattner via swift-evolution > wrote: > > >> On May 27, 2016, at 12:11 PM, Joe Groff > > wrote: >> >> Hello Swift community, >> >> The review of SE-0099 “Restructuring Condition

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On 30.05.2016 13:40, Haravikk via swift-evolution wrote: >... I understand that the need for semi-colon separators probably arose as a requirement of removing where, but I think it makes more sense to cover semi-colons first as a result, and come back to removing where clauses afterwards.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On 29 May 2016, at 20:39, Chris Lattner wrote: > >> On May 29, 2016, at 3:55 AM, Haravikk > > wrote: On May 27, 2016, at 12:11 PM, Joe Groff > wrote:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

+1 from me as well. On Sun, May 29, 2016 at 18:39 David Hart via swift-evolution < swift-evolution@swift.org> wrote: > +1 again. > > On 29 May 2016, at 21:39, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > On May 29, 2016, at 3:55 AM, Haravikk

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 29, 2016, at 3:39 PM, Chris Lattner via swift-evolution > wrote: > > I can definitely respect the position that “where” feels more readable than a > semicolon, it certainly provides a more “fluent” style. > > That said, the existing Swift 2 syntax was

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

+1 again. > On 29 May 2016, at 21:39, Chris Lattner via swift-evolution > wrote: > >> On May 29, 2016, at 3:55 AM, Haravikk wrote: On May 27, 2016, at 12:11 PM, Joe Groff wrote: Hello Swift community,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 29, 2016, at 3:55 AM, Haravikk wrote: >>> On May 27, 2016, at 12:11 PM, Joe Groff >> > wrote: >>> >>> Hello Swift community, >>> >>> The review of SE-0099 “Restructuring Condition Clauses” begins now and runs

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> Am 28.05.2016 um 22:35 schrieb Chris Lattner : > > >> On May 28, 2016, at 12:07 PM, Thorsten Seitz wrote: >> >> What about requiring `let` before each binding and `case` before each >> pattern? >> >> guard case let x = a, case let y = b, let z = c,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On 28 May 2016, at 23:48, Chris Lattner via swift-evolution > wrote: > > >> On May 27, 2016, at 12:11 PM, Joe Groff > > wrote: >> >> Hello Swift community, >> >> The review of SE-0099 “Restructuring Condition Clauses”

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

New proposal looks great. I love how this brings more consistency with how normal statements are written. It would be nice to see in the proposal examples of before & afters for `while` too. Especially as it says "where clauses are no longer used to conjoin Boolean expressions with conditional

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 12:11 PM, Joe Groff wrote: > > Hello Swift community, > > The review of SE-0099 “Restructuring Condition Clauses” begins now and runs > through June 3, 2016. The proposal is available here: > > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 28, 2016, at 12:07 PM, Thorsten Seitz wrote: > > What about requiring `let` before each binding and `case` before each pattern? > > guard case let x = a, case let y = b, let z = c, x == y else { … } > > Now `let z = c` can only be a let-binding and not a pattern

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

I'm not sure how feasible this is...but why not remove the conditional case to remove the ambiguity? Conditional case seems somewhat esoteric compared to the current behavior that many people are used to. (I.e. How many know of and use a conditional case?) Is it worth de-beautifying the syntax

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Sent from my iPad > On May 28, 2016, at 12:33 PM, Chris Lattner wrote: > > >> On May 28, 2016, at 10:18 AM, Matthew Johnson wrote: >> Given the whole newline groundswell that has emerged on SE, I did consider it but when I mocked

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

• What is your evaluation of the proposal? +1 • Is the problem being addressed significant enough to warrant a change to Swift? Yes. I have often been frustrated by needing to break up conditions to make complex checks. I am not completely sure that this proposal addresses that issue but it is

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 28, 2016, at 10:18 AM, Matthew Johnson wrote: > >>> >>> Given the whole newline groundswell that has emerged on SE, I did consider >>> it but when I mocked up examples, it felt less readable and I suspect it >>> would negatively affect the clarity of parsing

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 4:35 PM, Brent Royal-Gordon via swift-evolution > wrote: > I am not a fan of this syntax. `;` reads very strongly as a statement ender > to me, Technically speaking, Swift uses semicolon as a separator, not a line ender. We already use it to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Sent from my iPad > On May 28, 2016, at 12:11 PM, Chris Lattner wrote: > > On May 27, 2016, at 12:37 PM, Erica Sadun via swift-evolution > wrote: On May 27, 2016, at 1:28 PM, Matthew Johnson via swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On May 27, 2016, at 12:37 PM, Erica Sadun via swift-evolution wrote: >> On May 27, 2016, at 1:28 PM, Matthew Johnson via swift-evolution >> wrote: >>> • What is your evaluation of the proposal? >> >> +1. I believe it improves the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Perhaps, but it is a much bigger change and a different proposal topic entirely. Given how variable declarations work now, Erica's proposed syntax to replace where clauses is the most elegant solution, IMO. On Sat, May 28, 2016 at 04:15 Goffredo Marocchi via swift-evolution <

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

This I would not cry about. In other languages they are more of a source of pain than anything else. Sent from my iPhone > On 28 May 2016, at 09:10, David Hart via swift-evolution > wrote: > > Yet another alternative: would it be possible to disallow commas as

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Yet another alternative: would it be possible to disallow commas as variable declaration separators and use them for condition clause separators again: let a = 4, b = 8 // becomes illegal and requires to separate them on two lines if a > 4, let c = foo(), let d = bar(), c != d { // now comma is

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Agreed! Sent from my iPhone > On 28 May 2016, at 08:10, L. Mihalkovic via swift-evolution > wrote: > > >> On May 28, 2016, at 2:30 AM, Erica Sadun via swift-evolution >> wrote: >> >> On May 27, 2016, at 6:26 PM, Brent

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 28, 2016, at 2:30 AM, Erica Sadun via swift-evolution > wrote: > > >>> On May 27, 2016, at 6:26 PM, Brent Royal-Gordon >>> wrote: >>> >>> guard >>> x == 0 && a == b && c == d && >>> let y = optional, w = optional2, v = optional 3

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> 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. Yes, which is quite intentional on my part. The `if` statement requires

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Golang has IMO successfully used this in their IF statement. Coming from a recent imersion into the language, it is not as distracting in real life code on a day to day basis, as it might seem to be when first seen in a spec. Considering the parallel with the swift guard, this is IMO a nice

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 6:26 PM, Brent Royal-Gordon > wrote: > >> guard >> x == 0 && a == b && c == d && >> let y = optional, w = optional2, v = optional 3 && >> z == 2 >> else { ... } >> >> Figuring out where to break the first line into expression and into >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> guard > x == 0 && a == b && c == d && > let y = optional, w = optional2, v = optional 3 && > z == 2 > else { ... } > > Figuring out where to break the first line into expression and into condition > (after the `d`) could be very challenging to the compiler. I'm not sure it is. `let` and

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> > https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md > • What is your evaluation of the proposal? Oof. I am not a fan of this syntax. `;` reads very strongly as a statement ender to me, and yet at the same time, it's still visually

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

On May 27, 2016, at 1:47 PM, Matthew Johnson wrote: > >> >> On May 27, 2016, at 2:37 PM, Erica Sadun > > wrote: >> Given the whole newline groundswell that has emerged on SE, I did consider >> it but when I mocked up

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 2:37 PM, Erica Sadun wrote: > > >> On May 27, 2016, at 1:28 PM, Matthew Johnson via swift-evolution >> wrote: >> >>> • What is your evaluation of the proposal? >> >> +1. I believe it improves the clarity of

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> On May 27, 2016, at 1:28 PM, Matthew Johnson via swift-evolution > wrote: > >> • What is your evaluation of the proposal? > > +1. I believe it improves the clarity of condition clauses and as the > proposal suggests, I think it will make it easier for

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

> • What is your evaluation of the proposal? +1. I believe it improves the clarity of condition clauses and as the proposal suggests, I think it will make it easier for programmers to learn and understand what is possible with them. Did you consider allowing the semicolon to be omitted