Feature: "!==" assign if not equals

[Flithor]

int property;
int Property
{
    get => property;
    set
    {
        property = value;
        //Do some others
    }
}
//...
Property !== newValue; // returns new value

OR

int property;
int Property
{
    get => property;
    set
    {
        if(property !== value) // returns bool
        {
            //Do some others
        }
    }
}
//...
Property = newValue; 

Tired to write:

if(Property != newValue)
    Property = newValue;

[theunrepentantgeek]

Why is this necessary? What value does this provide except to make code trivially shorter?

Making code shorter is not generally considered a sufficient goal.

[CyrusNajmabadi]

This would look far too similar to the JavaScript !== operator and would likely lead to far too much confusion.

[dstarkowski]

From API consumer perspective I'd expect setting property to be idempotent and (regardless of initial value or how many times I assign it) the end effect to be exactly the same - setting property value and nothing else. If it sets value and does stuff it should be SetValueAndDoStuff(int value) method instead of property.

If you have some internal logic bound to property setter that requires this kind of check (like INotifyPropertyChanged or change tracking) it should imo be handled internally.

[MgSam]

Making code shorter is not generally considered a sufficient goal.

@theunrepentantgeek Are you sure you follow C# lang development? :)

[jnm2]

@MgSam I think the team may have rejected more ideas for making things shorter than the ideas they shipped. That would mean that the relevant factor wasn't length in isolation.

[MgSam]

@jnm2 A substantial portion of language design notes is the team agonizing over how to shave off every possible character.

• record vs record class being the best most recent example. They chose conciseness over clarity despite the overwhelming opposition of the community on Github.
• in keyword being another great example. Conciseness over clarity.
• The postfix ! operator for null checking parameters just saves a few characters.
• The ??= operator that was recently added saves only a few characters.
• The entire pattern matching feature set at most saves a few characters over traditional if/switch statements. (Before you mention exhaustiveness checks- this was already possible without any new language features- R# has for years provided a warning if it saw you switching over an enum without covering all cases)
• The records feature itself is mostly just to reduce boilerplate. The only really new features are withers and init; setters.

All that said I'm not in favor of this proposal as I think the use case is exceptionally narrow and the operator confusing for the reason Cyrus stated.

[jnm2]

I don't think reducing boilerplate is the same thing as agonizing over shaving off characters. It's not about the characters, it's about the readability. If it was about minimizing characters, it would go too far and actually diminish readability.

Most of the things you mention are reducing active areas of pain and annoyance. Character count is incidental.

[MgSam]

You say tomato and I say tomahto. "Enhancing readability" vs "shaving off characters" seems like semantics to me. I'm sure a Perl developer would tell you its the most readable language in the world.

record and in both seem equally "readable" in their more verbose forms as record class, ref readonly.

My point is only that the C# team the past several years is highly motivated by reducing characters at all costs and the decisions the LDM has made make this pretty clear. Whether this is a good or bad thing is for the larger C# community to decide.

[CyrusNajmabadi]

My point is only that the C# team the past several years is highly motivated by reducing characters at all costs

This is not the case. Of your list, the only one that hits in terms of decision making was !, and that isn't even something we've done yet.

and the decisions the LDM has made make this pretty clear

The decisions were not made with the motivation of reducing characters at all costs.

[CyrusNajmabadi]

They chose conciseness over clarity despite the overwhelming opposition of the community on Github.

I disagree. I don't think record class is more clear. I think it's less clear as i don't think record is a 'modifier' for anything. I think of record as a thing on its own. For me the more clear thing is also the more concise thing.

The ??= operator that was recently added saves only a few characters.

This was added for clarity and consistency. We already had all the other associated binary operators have both forms. So this was just smoothed out this special case. This was also not about saving characters, but about not repeating yourself. i.e. the primary goal is to not have to write redundant stuff. It turns out that not writing redundant things tends to make it shorter. But that's a consequence of the original desire (reducing redundancy) not reducing characters.

[CyrusNajmabadi]

The records feature itself is mostly just to reduce boilerplate

Your position has changed in teh very same post. IT started with " agonizing over how to shave off every possible character." to "reducing boilerplate". These are not the same things. 'Boilerplate' is dealing with lots of repetition that masks the signal with too much noise. The goal is to expose signal and reduce noise. THat doesn't at all mean shaving off characters. Indeed, it may introduce more characters, just with the desire of making you repeat them a lot less. It's the repetition and frequency of these patterns (no pun intended) that are not addressed, not just a desire to remove characters at all cost, or to shave off everything that coudl be possible shaved off.

If the latter was a goal we would have a very different language and we would approach all design very differently.

[CyrusNajmabadi]

"Enhancing readability" vs "shaving off characters" seems like semantics to me.

It isn't. We could shave off tons of characters if that were a goal. Many (most?) are unnecessary in C# from a strict language-design perspective. However, they serve a ton of purpose in terms of clarity and code structure. Even the ; is likely to never be touched, despite it being one of the most common chars out there, and despite it being totally possible that we could remove it (without the mistakes that JS made). That's because the team feels that "shav[ing] off every possible character" is nto a goal, and that we should absolutely keep and embrace syntax that we think aids the readability and clarity of the language.

[Flithor]

This would look far too similar to the JavaScript !== operator and would likely lead to far too much confusion.

yes, !== in javascript is very confusion, but we can exactly define its behavior in c#.
For the two behaviors I preset, I prefer the latter (return bool).
It can add other statements that meet the assignment conditions after it, and the former can only be used for assignment.

[theunrepentantgeek]

In JavaScript the operator !== is an equality operator that checks both value and type.

The proposed use in C# for !== is an assignment operator.

That's very very different @Flithor and extremely likely to cause confusion as developers move between languages. I believe that's why @CyrusNajmabadi made their comment.

[Flithor]

In JavaScript the operator !== is an equality operator that checks both value and type.

The proposed use in C# for !== is an assignment operator.

That's very very different @Flithor and extremely likely to cause confusion as developers move between languages. I believe that's why @CyrusNajmabadi made their comment.

How about toString in java and ToString in C#?
Or @attribute in java and @variable in C#?
Or ()->{} in java and ()=>{} in C#?
That's just a define.

[svick]

@Flithor Differences between languages are okay. What is not okay is if you have two completely different features that use the same syntax in the same context. The only one of your examples that gets close is @annotation vs. @variable, but those can't really be confused for each other, because they are not used in the same way (compare @Annotation int i = 42; with int @i = 42;).

[CyrusNajmabadi]

yes, !== in javascript is very confusion, but we can exactly define its behavior in c#.

It's not about exactly defining the behavior. It's that in one language is a binary comparison operator and I'm the other is an assignment operator.

JS and TS are too well known and ubiquitous for me to take one of their operators but find it an entirely different meaning.

We could certainly use it as a comparison operator of some sort. For example, it could be a short hand for 'reference equals'. However, making it a shorthand for assignment is not going to happen.

[Flithor]

yes, !== in javascript is very confusion, but we can exactly define its behavior in c#.

It's not about exactly defining the behavior. It's that in one language is a binary comparison operator and I'm the other is an assignment operator.

JS and TS are too well known and ubiquitous for me to take one of their operators but find it an entirely different meaning.

We could certainly use it as a comparison operator of some sort. For example, it could be a short hand for 'reference equals'. However, making it a shorthand for assignment is not going to happen.

It's still has "comparer" feathre! but not only comparer!

[CyrusNajmabadi]

It's still has "comparer" feathre! but not only comparer!

I don't know what that means.

[Frozenthia]

If it really bothers you, this has less characters.

public static void Set<T>(this T val, ref T target)
{
    var comparer = EqualityComparer<T>.Default;

    if (comparer.Equals(target, val) == false)
    {
        target = val;
    }
}

int property;
int Property
{
    get => property;
    set
    {
        value.Set(ref property);
    }
}

[Flutterish]

!== and === have the same format as += and I'd expect it to work only on booleans which is not very useful at all especially given the confusion they would introduce to js programmers.
I would expect x !== y to be exactly x ^= y and x === y to be x ^= !y and not some kind of "assign if not equals"