> How do you propose to construct these operators? Is [!] an
> operator all its own, or do the commas between terms factor
> in for a variable number of commas to be possibly attached
> to the name/definition of each of your four operators?

The thought is that they are pseudo-operators that merely expand to the equivalent conditions.

> Is A [!] B strictly equivalent to A != B or is there enough
> difference in how they work internally that you can't make that
> guarantee?

Strictly equivalent. Preference would be to emit a mandated compiler warning in single-value scenarios informing the user to use the existing operator ==/!=.

> I assume these aren't overloadable operators and you have a
> reasonable idea of details like precedence figured out

No overloading, as is the case with the Ternary operator. Precedence would follow the equivalent comparison operators ==/!=.

> have you looked at how it would interact with the existing
> standard in terms of wording; including all the various fringe
> cases and bits that adding new operators and conditionals will
> have when pathologically arranged?

I will have to acknowledge my naivety on the matter. No.

Regards,
Ben Crowhurst

-------- Original Message --------
On 8 Sept 2023, 16:41, Matthew Taylor < mjtaylor214_at_[hidden]> wrote:

>
>
> I'm not sure I'd agree that a brand new set of operators is necessarily easier to read than the template solution; particularly if you start to stack up more complex or compound uses. To borrow a suggestion which has already been given to you, consider
>
> if(matcher(Alpha).is_none_of(Beta,Gamma,Delta) && matcher(Alpha).is_any_of(Epsilon,Zeta,Eta) && matcher(Theta).is_any_of(.....) && ...)
>
> vs
>
> if(Alpha [!] Beta, Gamma, Delta && Alpha[^] Epsilon, Zeta, Eta && Theta [^] ... && ....)
>
> I'd argue cognitive load goes up from needing to track the three-character symbols and their relative positions between a bunch of names (especially consider if the names themselves become compounded names or function calls); over a more traditional function call syntax. It adds more characters, yes, but verbosity is not a dirty word if it means making the code clearer. I will agree that the need to insert a wrapping "matcher" template is unideal, but that's how the language works; and adding something as extraordinarily fundamental as a new set of operators to the language requires an extraordinary motivation which in the nicest possible way I don't quite see here.
>
> How do you propose to construct these operators? Is [!] an operator all its own, or do the commas between terms factor in for a variable number of commas to be possibly attached to the name/definition of each of your four operators? Is A [!] B strictly equivalent to A != B or is there enough difference in how they work internally that you can't make that guarantee? I assume these aren't overloadable operators and you have a reasonable idea of details like precedence figured out - have you looked at how it would interact with the existing standard in terms of wording; including all the various fringe cases and bits that adding new operators and conditionals will have when pathologically arranged? I dread to think how many places the standard refers to operators and constructs which can be treated as conditionals and predicates, so there may well be wording awkwardness aplenty.
>
> Kind regards,
> Matthew Taylor