[swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

[Roth Michaels]

While I did not get a chance to review all the discussion in time to
respond to the proposal, I am happy with the revised version that was
approved (the semi-colons were a point of concern for me).  In addition
to resolving ambiguity, this also resolved a pedigogical issue
surrounding the 'where' keyword I encountered when teaching Swift.

On Wed, Jun 08 2016 at 09:47:55 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 'where' keyword can be retired from its purpose as a boolean condition
> introducer.

When teaching Swift, I did discover that the requirement of 'where' in
conditionals as expressed by this proposal was confusing and those I was
teaching assumed they would use commas (or &&).

I'll admit that at first the 'where' keyword surprised me as well, but I
grew to like it and will be a little sad to see it replaced by comma
instead of allowing 'where' or comma as I thought certain statements
were easier to read with 'where'.

On Thu, Jun 09 2016 at 06:30:17 AM, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
>     On 9 Jun 2016, at 09:47, Brent Royal-Gordon
>     <brent at architechies.com> wrote:
>
>     
>     
>         Can we get some clarification as to why ‘where’ is being chosen
>         to be retired here? I’m deeply disappointed by that decision as
>         enabling the consistent use of comma as a separator does not
>         preclude the use of where for simple cases that don’t require
>         it. I’m all for having a more usable separator for complex
>         conditionals, but I rarely need it, meanwhile in common, simple
>         conditional bindings and patterns I find the ‘where’ keyword a
>         lot more readable, i.e:
>         
>         if let value = foo where foo > 5 { … }
>         
>
>     I think there may be a case for keeping the `where` keyword—but
>     before, not after, the equals sign.
>     
>     if case .cartesian(let x, let y) where x != y = point { ... }
>     if let value where value > 5 = foo { … }
>     
>
> That looks pretty strange visually though thanks to the assignment (it
> kind of looks like x is being compared against y = point).

I had this feeling as well.

> While my reasons for liking where are mainly aesthetic once the need to
> use it to get around separator issues goes away, it’s still a nice tool
> for grouping statements visually, for example:

This is the case for me as well, functionally I suppose I will not miss
'where', but for aesthetics I do think it made some statements cmore
clear to read.

--
Roth