> 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
