Shorthand for: "Bool = !Bool" Instead use: "Bool = !!" (inverts it)

[najak3d]

As this site has opened my mind to looking at my "decade-old unchanged coding style", to figure out how to adapt my style to take on the progress of the C# language.

I went looking for a solution to something that is fairly annoying that should have better notation - which is for flipping a bool value.

I often write stuff that looks like this:

      {object}.{member}.boolValue = !{object}.{member}.boolValue;

And realize that there exists a fairly cryptic/mind-bending shorthand for this now, which is:

      {object}.{member}.boolValue ^= true;   // this inverts the bool value.

But that isn't an intuitive notation.

Instead, I'd suggest the following notation:

     {object}.{member}.boolValue = !!;

This avoids writing the same expression twice (can be error prone) and also avoids the cryptic "^= true" notation.

Thoughts?

EDIT: Note this proposal was edited based on the initial feedback of @CyrusNajmabadi - so his first response here no longer makes sense to this now edited proposal.

[CyrusNajmabadi]

!! already has meaning in c# in another location (parameter lists) and we are contemplating bringing that syntax to also mean something in the method body. THis proposal would collide with that.

[CyrusNajmabadi]

I'm definitely up for hearing what others think!

[najak3d]

Great, then I'm going to EDIT my initial post.. or delete it and repost it, so that it's clean.

If I EDIT it, we should delete these comments so that it's clean (i.e your initial response wouldn't make sense anymore)

[najak3d]

OK - it's now edited -- can you use your admin privileges to remove all of these comments... so that it looks brand new again?

[CyrusNajmabadi]

Uh no :) The point of a discussion is to discuss, and to go all through these things :)

[DavidArno]

Sorry, but I cannot see why ^= true is supposed to be cryptic but = !! is supposed to be easy to understand. They both look cryptic to me.

There are already multiple ways of inverting a bool value in C#. I don't see any benefit to adding yet another, especially one that is so unintuitive.

[najak3d]

The intuitive part is "!" already means "NOT" - and inverts a boolean. And the "!!" is similar to "++" then, a unary operator.

If you google this issue, they'll tell you repeatedly that the best available shorthand is "^= true", but "why does that work?" It's a bit of a mind-twister, as most don't use the XOR operation for much at all. If you logic through it, you can figure out it's an inverter.

What other easy means of inversion did you have in mind?

The primary issues I run into are for a deep bool value, such as:

 Services.Resolve<MyService>.MemberObject.BoolValue = !Services.Resolve<MyService>.MemberObject.BoolValue;

would instead become:

 Services.Resolve<MyService>.MemberObject.BoolValue = !!;

and I'd rather avoid this notation that I currently use:

Services.Resolve<MyService>.MemberObject.BoolValue ^= true;   

As it tends to confuse developers. It's a non-intuitive way to flip the bool.

Without documentation if you had to guess what the "bool = !!" did, "flipping the value" would be among the most common guesses, IMO.

[theunrepentantgeek]

if you had to guess what the "bool = !!" did

Given the pending introduction of !! for null value argument checking, I'd expect it to throw an exception.

You think it's easy to understand because you invented it, nothing more.

[najak3d]

I take it that you find nothing wrong with "bool = !bool" as the way it should be done. Or if not, what are your ideas?

I don't think it's easy to understand based on my invention... it's easy to understand because it's a simple concept, and draws on the usage of "!" to mean NOT, and "++/--" are unary operators. If not for the recent usage of "!!" suffix to mean NullArg check, I'd still be suggesting it just be "booValue!!". And I didn't invent it -- but several different people on forums suggested it, and that's where I got the idea that bringing the issue to this forum would be a good solution.

I'm NOT attached to "= !!" notation at all; I'd just like something more convenient and less error prone than "bool = !bool" and less cryptic than "^= true". Also I think having a unary operator has an advantage too - takes one clock cycle, guaranteed so is fully thread safe. It should work much like "int++" does.

[DavidArno]

The problem is, !! currently means "not not" to me when I see it. So = !! literally means invert then invert again back to where we started.

And then we have the issue that !! might mean "throw if null" in other contexts.

Finally we already have ^= true, which those that need it will learn.

So I genuinely don't see a need for another option here.

[CyrusNajmabadi]

I agree with David. In the context of booleans !! means to flip twice. So it would be extremely weird in the context of booleans for it to mean flip once.

[najak3d]

It seems to me that C# should have a unary-operator for "flip the bool", as the usage of this is about as common as the usage of "++", replacing "int = int + 1", with unary operator.

Can anyone else think of a more acceptable unary-operator notation?

Other options that come to mind:
boolValue^=;
boolValue^^; // similar to "int++" notation

[MadL1me]

I honestly think it shouldn't. I cant say for everyone, but in my daily work with code (I work in enterprise) and across different domains as a hobby (game dev with unity, desktop dev with avalonia ui, web dev with asp.net core) I rarely even need to flip booleans. Moreover, having to write 'bool = !bool' is not a big deal for me (and I think for most people who use csharplang down there)

[najak3d]

It appears that I am gifted with the ability of producing bad ideas to solve non-problems. But gifts are meant to be used. My purpose here must be to provide bad ideas created for shooting practice. Rock on.

[Rekkonnect]

The idea of a syntax that doesn't include an expression in the LHS, but provides the operator to be applied on the same expression in the RHS is obscure for C#. But I can see what it aims to provide.

Aside from b = !b, there also is the case of negating a numeric value (value = -value). There is no no-brainer way to negate or invert the given expression, but introducing brand new keywords or syntax for that purpose is an idea I cannot get behind myself. That means no invert b; or negate value; respectively.

What can be done though is this pattern of LHS = op, where op is the operator to apply. This would transform into LHS = opLHS. For example, the two above statements would become b = !, indicating that the ! operator will be applied, and value = -. This would be valid for all unary operators, as long as they don't cause any ambiguity, in which case there is none.

It won't look that great, expr = op is not as intuitive as it aims to be for ones that know how they function. And they surely break the pattern of having expressions in the RHS of whatever assignment. However, duplicating the operator sign like ++ and -- is not a solution either. From the early days of C, they figured they could do this as a shorthand for loops and iterations, a rather crucial operation, for which they reserved those operators. C# inherited those operations because they were trying to follow common syntax patterns of C. Python didn't adopt this design choise (++ and --), which has both its upsides and downsides.

Currently I have no other proposals for tackling this problem. Unfortunately, expression repetition is necessary if you want to perform these operations, or you can do the following hacks:

• b = !b => b ^= true
• value = ~value => value ^= int.MaxValue

Bitwise operation hacks are not something most C# developers are familiar with, meaning there currently is no real practical solution for this minor inconvenience. Some brainstorming is definitely required.

[Last8Exile]

value = ~value => value ^= int.MaxValue
Is it correct? I think correct way is:
value = ~value => value ^= -1

[CyrusNajmabadi]

    public static void Invert(this ref bool b)
        => b = !b;

// ...

someBool.Invert();

[najak3d]

@CyrusNajmabadi - would this work correctly if 'b' was a property, i.e. "public b {get; set; }" ?? Or does this extension only work for local variables and fields? If it works for properties, then seems viable, other than the inconvenience/risk of not having those extensions defined (i.e you code can no longer be cut-pasted or universally understood, without presence of that extension method).

I think it would be good for C# to offer a solution for the inversion of both 'bool' and 'numerics' (as mentioned by @alfasgd above, you just as often need to negate a numeric). Relying upon extensions isn't the best, unless it became a standard "System" namespace extension, and thus was semi-universal to the C# language.

At least for numeric negating we have "*= -1" which is at least not a brain-bender (vs. "bool ^= true" is more of a brain bender).

[CyrusNajmabadi]

@CyrusNajmabadi - would this work correctly if 'b' was a property

It will give the proposals to allow properties to be used in ref-contexts.

I think it would be good for C# to offer a solution for the inversion of both 'bool' and 'numerics' (as mentioned by @alfasgd above, you just as often need to negate a numeric)

Negating a numeric seems pretty uncommon. When do you have a value like 15 stored somewhere, and you want it to noe be -15? I'm not getting the use cases.

Relying upon extensions isn't the best, unless it became a standard "System" namespace extension

Why though?

Things in the language should be for either very common cases, or should be hugely important to a smaller, but very significant subset of the ecosystem. These appear to be neither.

[najak3d]

If a project decides to make use of an Extension method by convention -- then all of that code faces cut-paste portability issues -- in that it no longer "stands alone", and will yield compiler errors if the destination location doesn't also include such an extension.

For example "linq" at least is part of .NET, so this is more acceptable. But if ".Invert()" is only part of your own custom code, that makes this a potential issue.

Also, even with Linq, you could redefine all of the linq extensions simply by changing the "using" at the top of any file. This just makes the meaning of code more ambiguous when you use extensions.

So, is better to have certain functions be "part of the language" and if an extension is needed, it's better if it were part of the standard .NET platform (System... namespace). Otherwise, I'd never make use of an extension like "bool.Invert()".

Until C# changes, I may resort to "^= true". But right now, my fingers don't even know where the "^" key is... I have to look down and find it with my eyes... That's why I was hoping the solution could just use the '!' sign. The "^= true" currently requires me to look at the keyboard. I'm guessing I'm not alone in not having the "^" memorized by my fingers... I would expect this is quite common. And "^= true" is a brain-twister, unless you use the XOR concept a lot.

I do agree that having a unary numeric Negate operator is not really needed, because it's used less frequently, and also because "*= -1" is both intuitive, and easy to type (common characters for most devs).

[CyrusNajmabadi]

If a project decides to make use of an Extension method by convention -- then all of that code faces cut-paste portability issues -- in that it no longer "stands alone", and will yield compiler errors if the destination location doesn't also include such an extension.

This is the nature of all libraries. But literally 99.99% of all library code is stuff not likely to make it to the language.

[najak3d]

That's my point. If you want to do something common/universal, it needs to either be done without extensions or if you do use them, it should be a .NET standard package -- not something custom.

Inverting a bool, is not a "domain-specific" thing to do, where niche/custom lib usage is expected. Inverting a bool is "universal". So I wouldn't propose any team to use "bool.Invert()" if it were done via a custom library, that now is attached to all of your code. It either needs to become a widespread standard, or it's probably not smart to do.

I think static methods tend to work best for specialized contexts, such as how Fluent-Pattern extensions provide this for rich object nested composition.

More generically linq extensions are also fine to use anywhere, because it's packaged with .NET.

[najak3d]

Apple's Swift language recently adopted the "bool.toggle()" method (works like a C# extension method).

Is the C# language group able to designate implicit methods like this? I.e. that "bool.Invert()" or "bool.Toggle()" always exists (without needing an extension). If so, then same thing may apply to numerics for "numeric.Negate()". These methods would behave the same as an extension method.

Someone on another forum suggested that we simply allow "++" to increment bool -- which technically makes 0 to 1, then wraps 1 back 0... and thus is a toggle.

 bool++;      // inverts it.  Mathematically this makes sense, given that a bool is just a "1-bit integer"

But if we were going to adopt a unary operator, I currently still prefer:

 bool^^;   

[najak3d]

Suggestion for unary operator for number negating would be:

 number*-;   // negates it, same as "*= -1;"

[The-Futurist]

But that isn't an intuitive notation.

It is for those who routinely use boolean logic, you'll see this kind of (admittedly unattractive) code all the time in certain domains, often when modifying or extracting specific bit regions within datum.