[Proposal] Post Assignment

[MkazemAkhgary]

we are familiar with post-increments (i++) and pre-increments (++i).

there is no post assignment, for example x +=2 or x = x + 2 are processed immediately. It would be nice to have such syntax to save few lines for simple logics. so I'm proposing new syntax for post-assignment.

Use ~= operator for post assignments.

here is simple example (real part of my code, local function):

int PostIncrement(ref int val) 
{
    var t = val;
    val = (val + 1) % (count + 1); // well, sort of special increment.
    return t;
}

Becomes:

int PostIncrement(ref int val) => val ~= (val + 1) % (count + 1);

---

Another example (swap x and y):

var t = x;
x = y;
y = t;

which in turn becomes

var t = x;
x = (y ~= t;)

which in turn becomes

var t = (x ~= (y ~= t));

---

How to read, rule of thumb

(lvalue ~= rvalue)

first lvalue is used, then rvalue is assigned to lvalue.

[jnm2]

While this has crossed my mind on several occasions, understandability tanks.

Not to mention that the syntax reads like shorthand for lvalue = lvalue ~ rvalue which makes no sense.

[HaloFour]

I already feel that the pre- and post-increment/decrement operators make it too difficult to discern exactly what the given code would do. I would hate to see more operators added in the same vein, especially one that doesn't behave like any other operator. Any syntax benefit would be minimal at best and I don't believe would be worth the immediate drop in readability.

Expressions, even those that contain operators, execute entirely independently of whether or not they are assigned. How would this operator behave when the result is not assigned to a variable?

[MkazemAkhgary]

@jnm2 ~ is unary operator. indeed it does not make sense, but why not take advantage of it. its not confusing or hard to understand for programmer that reads somewhere in a book what ~= actually do.

@HaloFour that's your opinion and indeed is respected, ~= will perform exactly same as = when its not assigned anywhere.

I always use post/pre increment expressions when ever I see its convenient. its by habit, I see it convenient most of the time.

As I said for simple logics, these operators serve you well, you can always use syntax in wrong way. its no different for this operator.

[MkazemAkhgary]

@HaloFour

How would this operator behave when the result is not assigned to a variable?

~= could be defined as expression. so such case would become impossible anyway.

[bondsbw]

I think declaration expressions (#595) can cover some or all of these use cases.

Though as written, declaration expressions might only work for new declarations and not reassignments.

[MkazemAkhgary]

@bondsbw can you elaborate more on how they can cover this scenario? I cant think of any way.

[bondsbw]

@MkazemAkhgary Actually I should have said "extended declaration expressions", and more generally "sequence expressions" which were proposed in #377.

int PostIncrement(ref int val) 
{
    var t = val;
    val = (val + 1) % (count + 1); // well, sort of special increment.
    return t;
}

can be replaced with

int PostIncrement(ref int val) => (var t = val; val = (val + 1) % (count + 1); t);

Granted, it's not really clearer. But it also doesn't introduce any new operators, and it can be used as an expression.

[MkazemAkhgary]

In my opinion extended declaration expression is far uglier than ~= but thats just my opinion @bondsbw

[MkazemAkhgary]

@bondsbw I take back my word, reading further I actually see it cleaner now 😃

[MkazemAkhgary]

just recalled another use case

if (_initialize ~= false) Initialize();

[jnm2]

You can also use if (Interlocked.Exchange(ref shouldInitialize, 0) == 1) but that is about six times slower because of the unnecessary thread sync overhead. A lightweight helper method could be written, though.