out var Property

[TonyValenti]

Hi All,
It would be really nice if I could pass a property to an outvar call. For example, currently I have to do this:

int.TryParse(txtAge.Text, out var temp);
Person.Age = temp;

It would be great if I could do this:
int.TryParse(txtAge.Tex, out Person.Age);

and when doing that, the compiler was smart enough to create a temporary variable and then assign it to the property.

[alrz]

You can already do that with any ref-returning method or property,

class C {
  ref int M(out int i)
    => ref M(out M(out i)); 
}

I'm not sure if it makes sense for it to work with non-refs, though.

[Joe4evr]

You can't use out with properties, because the compiler has to be sure that the target is writable, and properties encapsulate that writability.

[jnm2]

I've wanted this on a fair number of occasions.

@Joe4evr He didn't ask to pass the property as the out target, he explicitly asked that a temporary local be created and passed and then the property be assigned from the local after the return. So as far as writability goes, the check isn't any different than writing Person.Age = tempLocal; if you do it manually.

[HaloFour]

The compiler could certainly handle the syntax and behave as described using a temporary local, for both ref and out parameters. The compiler already knows whether the property is writable.

There is one place where the behavior wouldn't be consistent, though. If the method called modifies the reference the location is changed immediately and would be reflected on further inspection of that local/field. But that couldn't be the case with properties since you're relying on assignment after the method returns. At best the compiler could wrap the method call in a try/finally and force the assignment, which would catch situations where the parameter is written and then an exception is thrown, but it couldn't handle calls to other methods which might inspect the property directly.

[scalablecory]

If I can throw a wrench into the mix here:

Concurrency.

Consider e.g. SpinLock.Enter -- this method is written so that it requires the writes to the ref variable be immediately visible to other threads. Using a temporary here would break this method in a very non-obvious way.

Anything using special visibility/ordering guarantees, like Interlocked, lock, Volatile, etc. will be broken if operating on a temporary ref concurrently.

[tannergooding]

I think the one benefit here would be with being able to pass the backing field of an auto-prop for a read-write property (this is the primary blocker of auto-props in a lot of my personal projects, that and wanting to ensure field layout is exactly how I want it for interop).

The only other benefit is saving 1 line of code (the actual assignment from the temporary to the property) and I'm not sure that is enough of a reason to add this as a feature.

[CyrusNajmabadi]

VB already supports this. C# definitely coudl as well. There's no good reason, afaict, for C# to not support this.

[jnm2]

Consider e.g. SpinLock.Enter -- this method is written so that it requires the writes to the ref variable be immediately visible to other threads. Using a temporary here would break this method in a very non-obvious way.

Wait for it...

...

...analyzers. 😁

[DavidArno]

@jnm2,

How would analyzers help here?

[jnm2]

@DavidArno I meant it as a joke, but if you're serious, the analyzer would create an error if you ref something for SpinLock.Enter that causes a temporary local to be used.

[svick]

I think there is difference between ref and out, even if they're implemented the same.

With ref, the value can be read zero or more times and written zero or more times, at different times. Effectively reading the value just once before the method call and writing it once after the call would change the semantics too much.

On the other hand, with out, the value has to be written at least once (and if it's read, the method is just reading the value it wrote there itself), so writing it just once after the call doesn't change much.

Or is there some real-world code where it would make a difference that the value is written only once after the call for out parameters?

[scalablecory]

@svick Even if we ignore ref and only look at out, the problem remains. Here's an example:

static void DoStuff(out int i)
{
    lock (obj)
    {
        i = 0;
    }
}

In this case, i is guaranteed to be written to before the lock has exited. If i points to a temporary, there's a race because the temporary isn't subject to the barrier created by the lock:

DoStuff(out int temp_foo_Bar);
// lets say our thread ends its time slot here, and another thread
// executes code concurrently that uses `foo.Bar`. that concurrent
// thread will have an incomplete state to work with, but maybe it still
// completes (a silent failure). finally our thread resumes and maybe
// overwrites the work done by the other thread (another silent failure).
foo.Bar = temp_foo_Bar;

If we go even further, the foo.Bar assignment can be completely reordered by the CPU and might not execute until well later if the optimizer gets its hands on it.

[InDieTasten]

I would really like to out into a Property some way or another. I really dislike the need for manually creating and naming a local variable that is used only to assign it to the property next line.

[copernicus365]

Inability to pass properties as a ref or an out variable greatly complicates code, and often makes one regret auto-properties. But auto-properties are greatly needed for sanity and cleanness of code's sake. I wish this had been added at the same time as auto-properties. This goes beyond just a little thing of inconvenience.

Auto-properties ... this is the primary blocker of auto-props in a lot of my personal projects...

YES! I can't think of a bigger way of saying: we desperately need this.

The only other benefit [besides this inability working against use of auto-properties]...

But ah-hem, auto-properties are what, 90% of our properties?! Yes, without auto-properties, it wouldn't be a big deal, just use the backing variable, but auto-properties are the standard we always want to use when there is no reason not to otherwise (except for this very limitation!).

For those mentioning technical limitations to doing this... could limiting this to auto-properties solve those problems? Please let's get this done.

[scalablecory]

@copernicus365 limiting it to auto-properties could allow the compiler to use the backing field directly, and solve those problems. but, it creates another problem in that auto-properties are no longer just a syntax sugar but a distinct member type -- I don't think that inconsistency is worth it.

[HaloFour]

@scalablecory @copernicus365

Auto-implemented properties are an internal implementation detail. The consumer of such a type has no idea as to whether or not the property is an auto-implemented property or not, and certainly doesn't have direct access to any underlying backing field.

There really isn't any serious hurdles to supporting out/ref with read/write properties. As mentioned the VB.NET compiler already does this by automatically inserting the boilerplate of copying the value to a temporary local variable. The only inconsistency that will produce is that mutating the ref parameter within the method won't be immediately reflected by any other consumer attempting to read that property, which would be the case if you passed a ref to a field directly. But that inconsistency is probably more an academic problem.

[copernicus365]

There really isn't any serious hurdles to supporting out/ref with read/write properties. As mentioned the VB.NET compiler already does this

Bravo!

The only inconsistency that will produce is that mutating the ref parameter within the method won't be immediately reflected by any other consumer attempting to read that property, which would be the case if you passed a ref to a field directly.

This doesn't seem like much of a problem to me, in fact, the case could be made that this would be performing more consistently, in a way that is consistent with the nature of properties (a good thing). In the case of a field, it is true that the field could change at the top of the method that sets it as an out or ref parameter, and then that method might take some time before returning. It might even throw an exception, in which case the state of the Person instance still changes (if we were dealing let's say with a int _age; field), even though the method never even successfully returned. But this actually seems less consistent, I mean it's fine for fields, which often in these cases are just a local variable so it doesn't matter / doesn't change state of the type. But that is never the case with properties (ones with a backing field, whether auto-implemented or not). You could consider this just one further benefit of using properties, that they encapsulate a hidden field from direct manipulation from the outside, and in this case, the property only gets set upon a successful completion of a ref / out method call. This seems like better encapsulation, and one of the very reasons we use properties. Yes, they would behave a little differently, but in a way that is consistent and true to the nature of a property. An informed caller / dev will always be in the know of this, because they know they are setting a property, not a field.

[Adnaco]

Allow use property as described below:
void Parse(inout someProperty, string src), the same as void Parse(ref someField, string src)
intentions:

• no changes to someProperty if Parse is failed, keep old value.
• shorter then: someProperty = Parse(in someProperty, string src);