> Am 31.05.2016 um 23:01 schrieb Haravikk via swift-evolution > <swift-evolution@swift.org>: > > >> On 31 May 2016, at 18:57, Erica Sadun via swift-evolution >> <swift-evolution@swift.org> 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 a very good point!! I totally agree with that! -Thorsten > 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution