> On 9 Jun 2016, at 09:47, Brent Royal-Gordon <[email protected]> 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). It works better as you
proposed in a for where in loop since the in keyword keeps it separated nicely.
Even so, I prefer where coming after as it makes the condition secondary to
what it is I want to do, e.g- I want to bind a condition, but only if the where
clause succeeds.
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:
if let foo = maybeFoo where foo > 5, let bar = maybeBar where bar < 100
{ … }
Versus:
if let foo = maybeFoo, foo > 5, let bar = maybeBar, bar < 100 { … }
Even splitting these across two lines I prefer how the where clauses look in
terms of specifically indicating that the binding and condition are
related/distinct from the other pair. While I get that in this case it doesn’t
functionally do anything that the comma doesn’t, I’m not sure I agree that it
should be dropped as I’m perfectly capable of choosing for myself which to use
for my conditionals, and I prefer how the where looks visually in terms of
implying a direct relationship._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
