> On 31 May 2016, at 18:57, Erica Sadun via swift-evolution
> <[email protected]> wrote:
>
> * Should `where` clauses be allowed where the contents of the where clause
> have no connection to the condition that precedes it?
> * Is there a technical way to to check for such conformance?
> * Should the `where` clause be left unconstrained, as it currently is in
> switch statements and for loops, etc, which is consistent with the rest of
> the language but contrary to the spirit of safety in Swift?
> * Should `where` clauses be re-evaluated throughout the language?
Personally I’m not sure that where should need to be constrained, in fact one
of the examples given as “incorrect” is arguably not so:
if let foo = x where y < z { … }
In this case y < z doesn’t appear strictly related to the optional binding, but
it may still be a condition of it, in essence it’s saying “bind foo if this is
true”. This is interesting because the compiler is actually free to evaluate y
< z first, and only perform the binding afterwards. Actually this is also true
in the following case:
if let foo = x where foo > 5 { … }
To evaluate foo > 5 the compiler doesn’t actually need to unwrap x, it just
needs to know if x is .Some, in which case it can compare the value and only if
the comparison succeeds actually copy it into a variable and continue.
Of course statements separated by semi-colons can be reordered behind the
scenes if the compiler wants to do-so, so long as the logic doesn’t change, but
I find that where reads better with that implication in mind. It reads visually
like “bind this if this test is true” rather than “bind this, then test this”.
Plus it just looks nicer (to me); sometimes aesthetics are important, and the
majority of cases don’t need the complexity of lots of conditionals that need
separating, sometimes a pattern and a condition, or a binding and a condition
is enough, and the where clause has this covered, and keeps these forms of
conditional visually distinct. Much more complex cases will benefit from
semi-colons, which in turn will make them visually distinct too, even if a lot
of the building blocks are the same.
Put another way, I tend to think of pattern matching, conditional binding and
regular logic as three completely different forms of conditional (I suppose
they are in fact at present), the separators as proposed will let you mix and
match these cleanly, which has the potential for some overlap sure, but I think
developers can be left to resolve that for themselves by choosing whether to
group a conditional with where, or separate it.
Anyway, it doesn’t really matter overall, as the addition of
semi-colons/new-lines as separators isn’t dependent upon the removal of where
clauses, so they can be removed later if it’s deemed useful. In fact, doing it
this way would be a better way to do it as it gives us a period in which both
features will be available, and we can just wait and see what people actually
use. If where clauses are ignored in favour of semi-colons/new-lines, then at
this point it will be trivial to replace them, as you can non-destructively
remove the feature by simply swapping the where keyword from these types of
conditionals for a semi-colon, or provide a fixit to do this, as functionally
they will be identical._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
