Jonathan Grynspan
Jonathan Grynspan
Tracked internally as rdar://136052793.
I suspect we would probably implement this in terms of standard Boolean operators, not a bespoke DSL.
My thinking here was that we would implement `||` and `&&` operators that would compose multiple instances of `ConditionTrait` into compound ones (with additional implementation details inside the type to...
That's not quite how these operators combine today if you just use them _within_ a single trait, and I suspect that could be problematic. For instance: ```swift .disabled(if: x) ||...
Right, my gut sense is that `.disabled(if: x) || .disabled(if: y)` and `.disabled(if: x || y)` should evaluate to the same result (regardless of how we actually spell the symbols,...
If you're planning to start a proposal in the near future, I will be on leave and probably won't be able to help much with it. @stmontgomery would you be...
> Have we considered the how custom conditional traits can be used in the chosen solution? In general, we wouldn't advise folks to create their own types that do what...
> The only case can be problematic regardless of infix (custom operator) or prefix(DSL approach) situation is if ConditionTraits.Kind and init become public, and people introduce new methods like .pending...
@bkhouri That's already supported and functional though.
> But it's not explicit. I would like to have an equivalent of, where it's explicit, and where I can select `.all`, or `.any`, or whichever the API will allow....