Operator '=' chaining in C# - surely this test should pass?

Question

I was just writing a property setter and had a brain-wave about why we don't have to return the result of a set when a property might be involved in operator = chaining, i.e:

var a = (b.c = d);

(I've added the brackets for clarity - but it makes no difference in practise)

I started thinking - where does the C# compiler derive the value that is assigned to a in the above example?

Logic says that it should be from the result of the (b.c = d) operation but since that's implemented with a void set_blah(value) method it can't be.

So the only other options are:

• Re-read b.c after the assignment and use that value

• Re-use d

• Edit (since answered and comments from Eric) - there's a third option, which is what C# does: use the value written to b.c after any conversions have taken place

Now, to my mind, the correct reading of the above line of code is

set a to the result of setting b.c to d

I think that's a reasonable reading of the code - so I thought I'd test whether that is indeed what happens with a slightly contrived test - but ask yourself if you think it should pass or fail:

public class TestClass
{
  private bool _invertedBoolean;
  public bool InvertedBoolean
  {
    get
    {
      return _invertedBoolean;
    }
    set
    {
      //don't ask me why you would with a boolean,
      //but consider rounding on currency values, or
      //properties which clone their input value instead
      //of taking the reference.
      _invertedBoolean = !value;
    }
  }
}

[TestMethod]
public void ExampleTest()
{
  var t = new TestClass();
  bool result;
  result = (t.InvertedBoolean = true);
  Assert.IsFalse(result);
}

This test fails.

Closer examination of the IL that is generated for the code shows that the true value is loaded on to the stack, cloned with a dup command and then both are popped off in two successive assignments.

This technique works perfectly for fields, but to me seems terribly naive for properties where each is actually a method call where the actual final property value is not guaranteed to be the input value.

Now I know many people hate nested assignments etc etc, but the fact is the language lets you do them and so they should work as expected.

Perhaps I'm being really thick but to me this suggests an incorrect implementation of this pattern by the compiler (.Net 4 btw). But then is my expectation/reading of the code incorrect?

Answer 1

The result of an assignment x = {expr} is defined as the value evaluated from {expr}.

§14.14.1 Simple assignment (ECMA334 v4)

... The result of a simple assignment expression is the value assigned to the left operand. The result has the same type as the left operand, and is always classified as a value. ...

And note that the value assigned is the value already evaluated from d. Hence the implementation here is:

var tmp = (TypeOfC)d;
b.c = tmp;
a = tmp;

although I would also expect with optimisations enabled it will use the dup instruction rather than a local variable.