> Of these alternatives, the core team found the last one to be the best
> choice. 'case' and 'let' conditions should each specify a single declaration,
> comma should remain the condition separator, and the 'where' keyword can be
> retired from its purpose as a boolean condition introducer. Some code becomes
> more verbose, but in common formatting patterns, it aligns more nicely, as in:
>
> guard
> let x = foo(),
> let y = bar(),
> let z = bas(),
> x == y || y == z else {
> }
>
> and though it breaks commonality between 'let' conditions and 'let'
> declarations, it's more important to preserve higher-level consistency
> throughout the language in how components of expressions and statements are
> separated.
I think this is a pretty good way to split the baby, especially because it
actually improves an issue which always led to awkward indentation problems.
Even with this change, I believe you'll be able to avoid redundant `case`
keywords by using tuples:
guard case (.none, .none, .none) = (foo(), bar(), bas()) else {
However, if-let does not permit the analogous construct:
guard let (x, y, z) = (foo(), bar(), bas()) else {
Now that we're moving away from allowing compound if-lets, I think it might be
a good idea to revisit that decision. Would this be better handled as a
separate proposal?
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
