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

[Joe Groff]

> On Jun 9, 2016, at 12:53 AM, Haravikk <swift-evolution at haravikk.me> wrote:
> 
> 
>> On 9 Jun 2016, at 02:47, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> comma should remain the condition separator, and the 'where' keyword can be retired from its purpose as a boolean condition introducer.
> 
> 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 { … }
> 	if let value = foo, foo > 5 { … }
> 
> The latter just doesn’t read as cleanly to me, and these are the kinds of simple conditionals that I use a lot of. As such as I’d still prefer to have ‘where’ be usable in the simple case, and I feel it was a mistake for the SE-0099 to have it tied to changes to the separator as the two changes aren’t mutually exclusive.

Like the flounder and the human appendix, it was a vestige of incomplete evolution. Our current design emerged from an original design that attempted to unify "switch"-style pattern matching and "let"-style destructuring, the idea being that '<pattern> = <value>' should work for patterns that never fail to match, such as variable bindings and tuples, as a special case of 'switch <value> { case <pattern> where <condition>: }' or 'if <pattern> = <value> where <condition>', which would allow for arbitrary conditional pattern matching. We ultimately didn't go in that direction after getting strong negative feedback from our internal adopters, who had grown accustomed to the 'if let' sugar for optional binding.

-Joe