Mutually Exclusive OR Operators.

[Thor110]

This proposal introduces two new operators, XORA (^<) and XORB (^>), which would provide developers with a way to utilize the existing functionality of the XOR operator while explicitly stating whether the conditions are mutually exclusive.

For example:

if (!A && B)
else if (A && !B)

Could be written as:

if (A ^< B)
else if(A ^ B)

It's worth noting that the use of the XOR operator would naturally follow the use of the XORA or XORB operator.

[colejohnson66]

Personally, using XOR when dealing with booleans is already difficult enough. Assuming a and b are booleans, I'd much rather read (a != b) than if (a ^ b). Your suggestion to overload the meaning of XOR to have a precedence would get an instance "no" from me.

[huoyaoyuan]

To me its readability is much worse than:

switch (condition1, condition2)
{
    case (true, false):

    case (false, true):

    case (true, true):

    case (false, false):

}

And the compiler is already capable to optimize it into nested if-else:
https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA+ABATARgLABQGAzAATakDChA3oaQ+WRiqQLIAUwEEANqZAB2AEwCWAF1ERBOADSlufAdLGTpWAJT1GdAo32kAzgHcJYABakOQ1VJnybEu5u0HSut27ABDQzCviUACuMPIAZt68fhogrp5uGDgAnBwARACCqRoA3HHx+sCw3gDWuXr5DD5+VhFRoaSBITF5FeTJaQBCWWWtBoUwJT2tVf4cjfXjzeW9DIkpqZTdLRX9g8sGIzWRfuHbMFMzjHNpACJL0zOrpesAvnF3BDdAA

[Thor110]

To you perhaps, right but "if(textFile ^ contentType)" ( approx 28 lines assembly ) [including constructor method and class] compiles to less than "if(textFile && !contentType)" ( approx 38 lines assembly ) [including constructor method and class] then I figured perhaps an extension to the XOR operator might be beneficial.

Also it might optimise them, but it doesn't optimise them down to what you are presenting there which is a switch statement.

[CyrusNajmabadi]

To you perhaps, right but "if(textFile ^ contentType)" ( approx 28 lines assembly ) [including constructor method and class] compiles to less than "if(textFile && !contentType)" ( approx 38 lines assembly ) [including constructor method and class] then I figured perhaps an extension to the XOR operator might be beneficial.

Assembly results are not part of the language :) It's related to the compiler and jit. In this case, it seems like both can/should be updated to better detect these sorts of patterns and emit better code.

Def feel free to push on .net runtime on this.

[Thor110]

Wouldn't the introduction of a new operator to the language require changes be made to the compiler and jit to reflect this?

So making changes to the language would require changes throughout the systems that need to understand it.

I might be over thinking it and a switch statement might just be the best solution at least for my current use case, but as I imagined the problem with only two if statements I could see more potential use cases for the ability to define whether the XOR operator had a preference for which value should be more important.

[CyrusNajmabadi]

Wouldn't the introduction of a new operator to the language require changes be made to the compiler and jit to reflect this?

No. Most changes require no new IL changes or changes to the runtime's jit or aot compiler.

So making changes to the language would require changes throughout the systems that need to understand it.

This is almost never the case

I might be over thinking it and a switch statement might just be the best solution at least for my current use case, but as I imagined the problem with only two if statements I could see more potential use cases for the ability to define whether the XOR operator had a preference for which value should be more important.

Imo, a dev should not have to think about that sort of thing. Just express in a simple way (like the switch), and have the compilers do a good job. If they're not doing that currently, file a bug on code Gen improvements.

[erik-kallen]

IIRC VB had an operator called Imp or something for one of these. 3 seconds Google says that wasn't ported to VB.net, probably because no one used it.

[colejohnson66]

It's the "implies" boolean operator (officially material conditional). A->B (which is A Imp B in VB) is just !A||B. It (and it's sibling non-implies, A-/->B or A&&!B) are uncommon boolean operators because they're only really used in set theory. Not to mention that expressing them other boolean operators (the NOT, OR, and AND used prior) is a lot more logical to programmers.

[jnm2]

Yesss I was going to mention IMP from my qbasic days as a kid 😆

[erik-kallen]

So a^> b would be Not a Imp b