Upon accepting SE-0099, the core team is removing `where` clauses from condition clauses, writing "the 'where' keyword can be retired from its purpose as a boolean condition introducer."
Inspiried by Xiaodi Wu, I now propose removing `where` clauses from `for in` loops, where they are better expressed (and read) as guard conditions. Guard conditions can `continue` (mimicking the current use of `where`) or `break` (introducing the recently pitched `while` behavior). This limits the current situation where people new to the language expect `while` behavior and expect termination rather than sequence filtering. Removing `where` from for-in loops benefits these new users, reduces cognitive burden for all users, and enhances readability and predictability. I do not believe the same benefit would accrue in retiring `where` from `catch` clauses and `switch` statement cases. One can argue that there are inherent flaws in both situations: unlike generic constraints, nothing prevents semantic disjunction in their `where` clauses. That said, both measurably benefit from their `where` clauses in the current grammar: case_item_list : pattern where_clause? | pattern where_clause? ',' case_item_list catch_clause : 'catch' pattern? where_clause? code_block Case item lists allow comma-separated patterns in a single case statement. The only way to express a related Boolean assertion is through `where`. Catch clauses do not allow multiple patterns but I cannot think of an improved way to associate an assertion than `where`. -- E
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
