why C# does not provide internal helper for passing property as reference?

Question

This is issue about LANGUAGE DESIGN.

Please do not answer to the question until you read entire post! Thank you.

With all helpers existing in C# (like lambdas, or automatic properties) it is very odd for me that I cannot pass property by a reference. Let's say I would like to do that:

foo(ref my_class.prop);

I get error so I write instead:

{
   var tmp = my_class.prop;
   foo(tmp);
   my_class.prop = tmp;
}

And now it works. But please notice two things:

1. it is general template, I didn't put anywhere type, only "var", so it applies for all types and number of properties I have to pass

2. I have to do it over and over again, with no benefit -- it is mechanical work

The existing problem actually kills such useful functions as Swap. Swap is normally 3 lines long, but since it takes 2 references, calling it takes 5 lines. Of course it is nonsense and I simply write "swap" by hand each time I would like to call it. But this shows C# prevents reusable code, bad.

THE QUESTION

So -- what bad could happen if compiler automatically create temporary variables (as I do by hand), call the function, and assign the values back to properties? Is this any danger in it? I don't see it so I am curious what do you think why the design of this issue looks like it looks now.

Cheers,

EDIT As 280Z28 gave great examples for beating idea of automatically wrapping ref for properties I still think wrapping properties with temporary variables would be useful. Maybe something like this:

Swap(inout my_class.prop1,inout my_class.prop2);

Otherwise no real Swap for C# :-(

Answer 1

Properties are not variables, they are actually methods. Therefore, they cannot be passed as ref.

Answer 2

Because a property is a method. It is a language construct responding to a pattern of encapsulating the setting and retrieval of a private field through a set of methods. It is functionally equivalent to this:

class Foo
{
    private int _bar;
    public int GetBar( ) { return _bar; }
    public void SetBar( ) { _bar = value; }
}

Answer 3

There are a lot of assumptions you can make about the meaning and behavior of a ref parameter. For example,

Case 1:

int x;
Interlocked.Increment(ref x);

If you could pass a property by ref to this method, the call would be the same but it would completely defeat the semantics of the method.

Case 2:

void WaitForCompletion(ref bool trigger)
{
    while (!trigger)
        Thread.Sleep(1000);
}

Summary: A by-ref parameter passes the address of a memory location to the function. An implementation creating a temporary variable in order to "pass a property by reference" would be semantically equivalent to passing by value, which is precisely the behavior that you're disallowing when you make the parameter a ref one.

Answer 4

Because, as Eric Lippert is fond of pointing out, every language feature must be understood, designed, specified, implemented, tested and documented. And it's obviously not a common scenario/pain point.

Answer 5

So -- what bad could happen if compiler automatically create temporary variables (as I do by hand), call the function, and assign the values back to properties? Is this any danger in it?

The danger is that the compiler is doing something you don't know. Making the code confusing because properties are methods, not variables.

Answer 6

With a ref argument, changes to the underlying variable will be observed by the method, this won't happen in your case. In other words, it is not exactly the same.

Answer 7

var t = obj.prop;
foo(ref t);
obj.prop = t;

Here, side effects of getter and setter are only visible once each, regardless of how many times the "by-ref" parameter got assigned to.

Imagine a dynamically computed property. Its value might change at any time. With this construct, foo is not kept up to date even though the code suggests this ("I'm passing the property to the method")

Answer 8

Your proposal is called "copy in - copy out" reference semantics. Copy-in-copy-out semantics are subtly different from what we might call "ref to variable" semantics; different enough to be confusing and wrong in many situations. Others have already given you some examples; there are plenty more. For example:

void M() { F(ref this.p); }
void F(ref int x) { x = 123; B(); }
void B() { Console.WriteLine(this.p); }

If "this.p" is a property, with your proposal, this prints the old value of the property. If it is a field then it prints the new value.

Now imagine that you refactor a field to be a property. In the real language, that causes errors if you were passing a field by ref; the problem is brought to your attention. With your proposal, there is no error; instead, behaviour changes silently and subtly. That makes for bugs.

Consistency is important in C#, particularly in parts of the language that people find confusing, like reference semantics. I would want either references to always be copy-in-copy-out or never copy-in-copy-out. Doing it one way sometimes and another way other times seems like really bad design for C#, a language which values consistency over brevity.

Answer 9

I'll provide just one simple example where it would cause confusion. Assume it was possible (as is in VB):

class Weird {
   public int Prop { get; set; }
}

static void Test(ref int x) {
   x = 42;
   throw new Exception();
}

static void Main() { 
   int v = 10;
   try {
      Test(ref v);
   } catch {}
   Console.WriteLine(v); // prints 42

   var c = new Weird();
   c.Prop = 10;
   try {
      Test(ref c.Prop);
   } catch {}
   Console.WriteLine(c.Prop); // prints 10!!!
}

Nice. Isn't it?