Add dereference operator/keyword to complement the existing "ref" keyword.

[The-Futurist]

I wrote a generic method which returns " ref T " (T is "unmanaged") and its fine.

However when I call that method with the intention of getting the returned "ref" I must code this:

ref var datum = ref MyMethod<Whatever>(args);

But why? why is the "ref" required after the "=" above? since the method returns a "ref" why can't I just code:

var datum = MyMethod<Whatever>();

I suspect its because C# provides no dereference operator for "ref" values, with pointers we can write *pointer but for ref there is no such thing so how about adding a keyword or something?

If we take out the two "ref" keywords in the above assignment the code compiles but I get a local stack copy of the dereferenced "ref" returned by the method!

I'm arguing that this:

var datum = MyMethod<Whatever>();

should behave exactly like this (if the method returns a "ref")

ref var datum = ref MyMethod<Whatever>(args);

and if I actually wanted a local stack copy of the dereferenced result I should code this:

var datum = val MyMethod<Whatever>();

where "val" is just a suggested keyword that dereferences a ref!

Thoughts?

[HaloFour]

@Korporal

IIRC the team wanted the ref to be front and center so that the developer would be forced to acknowledge the fact that they were working with ref types and would have to deal with their constraints. The double ref on assignment to a ref local from a ref return was intentional.

[The-Futurist]

@HaloFour - OK that's a reasonable motive I guess, one could get into a mess if they weren't careful. However the code is verifiable (that is it is not unsafe) and I wonder why this particular scenario is treated as a special case? A programmer must understand what they write.

I can write

var datum = MyMethod<Whatever>();

where the method returns a pointer and it does behave as we expect (I get a local copy of the returned pointer not some automatically dereferenced value), this isn't treated as special like "ref" is.

[svick]

First of all, what you're proposing would be a breaking change, so I think there's pretty much zero chance that this would be accepted.

Second, I think the changes made in C# 7.x make sense, because they're consistent with how ref parameters and var behaved since C# 3.0. Consider this code:

void MyMethod(ref Whatever arg)
{
    var datum = arg;
}

Here, datum is not a ref local. But that means that if you wanted ref returns to behave consistently with ref parameters, var datum = MyMethod<Whatever>(); also has to create a variable that is not ref.

[The-Futurist]

@svick - Well I don't expect any major change to support what I'm asking, but it is unwieldy having to write this:

ref var datum = ref MyMethod<Whatever>(args);

for a method that itself returns a ref .

[svick]

So what kind of change that isn't a breaking change do you expect?

[tannergooding]

I agree that having to write ref var datum = ref MyMethod(args) can be a bit verbose (especially with code that is heavily using ref).

If anything, I would like to see the ability to do:
ref var datum = MyMethod(args) // MyMethod must be ref returning; otherwise, error
or
var datum = ref MyMethod(args) // datum is implicitly "ref"

I think the former (just requiring ref var) is possibly the better option as it still keeps the goal of having the refness be "front and center" (while the latter has it disappear in the middle of the statement).

[The-Futurist]

@tannergooding - Ineteresting:

I agree that having to write ref var datum = ref MyMethod(args) can be a bit verbose (especially with code that is heavily using ref).

If anything, I would like to see the ability to do:
ref var datum = MyMethod(args) // MyMethod must be ref returning; otherwise, error
or
var datum = ref MyMethod(args) // datum is implicitly "ref"

I think the former (just requiring ref var) is possibly the better option as it still keeps the goal of having the refness be "front and center" (while the latter has it disappear in the middle of the statement).

I actually began by coding

ref var datum = MyMethod(args)

only to end up spending time digging into how to actually code it. That syntax above seemed entirely natural to me and I fully expected it compile and run. I remember thinking to myself as I coded this:

ref var datum = ref MyMethod<Whatever>(args);

"...that's never gonna compile, I'm clutching at straws now..."

[The-Futurist]

@svick

So what kind of change that isn't a breaking change do you expect?

Tanner's suggestion (if that's what it is) seems absolutely fine.

[CoolDadTx]

I agree that the purpose was to call attention to it. I believe the syntax is consistent with the way out parameters work so I don't agree that anything needs to be changed.

Foo(out var someValue);

[The-Futurist]

@CoolDadTx @svick @tannergooding @HaloFour

I want to discuss this some more if I may. There is a subtle problem here that can lead to serious misbehavior at runtime.

If the following compiles:

ref var datum = ref MyMethod<Whatever>(args);

then so does the following:

var datum = MyMethod<Whatever>(args);

Yet these are not doing the same thing. It is only because I'm debugging and using the Memory windows under debug and I'm intimately familiar with manipulating raw memory and so on, that I discovered this.

As I mentioned in the OP I initially coded this and it compiled and ran:

var datum = MyMethod<Whatever>(args);

because MyMethod returns a ref I thought it was actually doing this:

ref var datum = ref MyMethod<Whatever>(args);

But it wasn't and I only discovered this because I'm debugging and examining memory and so on, I spotted that something was wrong because I'm very aware of what's going on with my code (by which I mean in this case MyMethod)

Any developer that simply consumed MyMethod<T>() without a firm understanding of this non-intuitive ref ref syntax could code this and see it compile and run and have no idea that the missing ref keywords are critical for correct execution.

This is not good, the thing being returned (a CLR reference) is the same in each case yet by declaring the variable datum with or without a ref we get different behavior, this is far from obvious and surely isn't good?

This really doesn't make sense to me and I don't know why anyone would intentionally design this. If a method returns a T then var x = Method() declares an instance - x - of T, but if the method returns a ref T then var x = Method() should surely declare an instance - x- of a ref T.

Note that when the method returns a T * then var x = Method() declares x as a T * so we can see that this is a most non-intuitive way to have to code with methods returning ref T.

These recent changes to C# are very very helpful and enable me to rewrite a lot of low level code that was previously written in C and accessed via interop. But as use of these features begins to proliferate then cases of someone forgetting about the ref ref syntax are going to arise and since the code compiles and runs fine there is real a risk that faulty code could go undetected or lead to nasty bugs.

There are other bizarre variations here too:

Whatever x = MyMethod<Whatever>();

compiles even though MyMethod is returning a ref, yet this doesn't compile !

ref Whatever x = MyMethod<Whatever>();

despite the fact that MyMethod is returning a ref !

A dereference keyword perhaps like 'val' might have helped hugely here:

Whatever x = val MyMethod<Whatever>(); // would compile

ref Whatever x = MyMethod<Whatever>(); // would compile

Whatever x = MyMethod<Whatever>(); // would still compile but issue warning about obsolete syntax

ref Whatever x = ref MyMethod<Whatever>(); // would still compile but issue a warning about obsolete syntax

Because C# makes references explicit via ref but dereferences implicit the symmetry is lost and this is where the problem begins I think.

[tannergooding]

@Korporal, it may help if you consider that ref T does not have the same semantics as T* (a pointer), but instead more closely resembles the T& syntax in C++ (a reference).

That is, even in standard C++, when using references, you have to explicitly indicate that you want a reference returning function to not implicitly dereference a given value. The same logic applies to C# here (with the caveat the C# gives an error if you do ref T x = MyMethod() or T x = ref MyMethod()... it requires you to do ref T x = ref MyMethod() currently).

C++ Example Code, displaying reference semantics

struct Int128
{
    uint64_t lower;
    int64_t upper;
};

Int128 MaxValue = { UINT64_MAX, INT64_MAX };

Int128& get_MaxValueRef()
{
    return MaxValue;
}

Int128* get_MaxValuePtr()
{
    return &MaxValue;
}

int main()
{
    Int128 maxValue = get_MaxValueRef();
    Int128& maxValueRef = get_MaxValueRef();
    Int128* maxValuePtr = get_MaxValuePtr();

    maxValue.upper = 0;

    // maxValue.upper = 0
    // maxValueRef.upper = UINT64_MAX
    // maxValuePtr.upper = UINT64_MAX

    maxValueRef.upper = 1;

    // maxValue.upper = 0
    // maxValueRef.upper = 1
    // maxValuePtr.upper = 1

    maxValuePtr->upper = 2;

    // maxValue.upper = 0
    // maxValueRef.upper = 2
    // maxValuePtr.upper = 2

    return 0;
}

[The-Futurist]

@tannergooding - What you say is true of course but C# is not C++ so there's no reason to use that language as the motivator for how to continue enhancing C#. Bear in mind most C# developers have probably never seen or used C or C++.

Explicit referencing with implicit dereferencing is not symmetrical and I think the "double ref" one needs in some of the examples above are evidence enough that this is somewhat messy now in C#.

The way var is defined in C# very naturally leads a developer to assume that this - which compiles and runs:

var datum = MyMethod<Whatever>(args);
datum.Member = 23;

results in datum being of type ref Whatever particularly if that developer has never seen C++. This is something the C# language has cemented in the mind of developers, the declared datum has a type that corresponds to the type of the expression assigned to it.

Of course you can say that var interprets an expression's type in the same way C++ does which includes implicit dereferencing but if most C# developers have never used C++ how can you expect them to know this?

[tannergooding]

but if most C# developers have never used C++ how can you expect them to know this?

Most C# developers also don't use ref or pointers 😄 (the closest thing the average C# developer gets to for those, is bool TryParse(string, out T)).

The way var is defined in C# very naturally leads a developer to assume that this - which compiles and runs:

Just seeing that could would make me assume that it isn't returning a ref, because that is the default case for 99% of existing C# code. If Whatever was a class, I would assume that the assignment would globally change the value of Member. If it was a struct, I would assume the assignment only impacted the local scope. Only after investigating the code further would I begin to assume something differently (because anything else is not the default state for the vast majority of code).

In any case, the way ref works (with implicit dereferencing) has already shipped. Modifying that behavior now is a breaking change (and so the bar for doing so is much, much higher).

[The-Futurist]

@tannergooding

Most C# developers also don't use ref or pointers 😄 (the closest thing the average C# developer gets to for those, is bool TryParse(string, out T)).

Except that the latest changes to C# in this area increase the utility of the ref concept and so one would assume will lead to some increase in the prevalence of ref code over what it is (assumed to be) today.

Just seeing that could would make me assume that it isn't returning a ref, because that is the default case for 99% of existing C# code.

Why would you assume it isn't returning a ref? just using intellisense you'd see that it returns a ref.

Surely of all the assumptions one could make about that statement the assumption that

var datum = MyMethod<Whatever>(args);

Leads to datum having a type that matches the methods result type, is the most rational assumption, I'd be truly surprised if the majority of C# developers assumed otherwise.

In any case, the way ref works (with implicit dereferencing) has already shipped. Modifying that behavior now is a breaking change (and so the bar for doing so is much, much higher).

Which is not true, I did suggest this for example:

A dereference keyword perhaps like 'val' might have helped hugely here:

Whatever x = val MyMethod<Whatever>(); // would compile

ref Whatever x = MyMethod<Whatever>(); // would compile

Whatever x = MyMethod<Whatever>(); // would still compile but issue warning about obsolete syntax

ref Whatever x = ref MyMethod<Whatever>(); // would still compile but issue a warning about obsolete syntax

I'm sure you'll agree this is not a breaking change.

Quite frankly if the current grammar with respect to ref exists in C# due to an unwillingness to break away from the poor grammar seen in C++ then I am not surprised but I am disappointed.

[tannergooding]

will lead to some increase in the prevalence of ref code

Yes, but it will still be in the minority of existing code.

Why would you assume it isn't returning a ref? just using intellisense you'd see that it returns a ref.

Generally speaking, you shouldn't have to use intellisense to understand code.

If I was in a meeting and someone was projecting that code (or interview and whiteboarding, etc...), my first assumption would not be that MyMethod returned ref.

Leads to datum having a type that matches the methods result type, is the most rational assumption, I'd be truly surprised if the majority of C# developers assumed otherwise.

Correct, which is why, given just that line of code. I would (by default) assume it returned Whatever and not ref Whatever.

// would still compile but issue warning about obsolete syntax
// would still compile but issue a warning about obsolete syntax

Adding new warnings is a breaking change due to /warnaserror. It means that my existing code, with no modifications other than a new compiler, breaks when recompiled.

There has been some discussion on fixing this with Warning Waves, but that doesn't exist yet.

A dereference keyword perhaps like 'val' might have helped hugely here:

Whenever adding a new keyword to an existing language you have to consider a lot of various cases like: What if the user has an existing type, local, parameter, or field with that name?

Quite frankly if the current grammar with respect to ref exists in C# due to an unwillingness to break away from the poor grammar seen in C++ then I am not surprised but I am disappointed.

refs have always been implicitly dereferencing in some form, the particular "issue" you are referring to is just exposed differently with ref returns and ref locals

Take:

public void MyMethod(ref Guid guidRef)
{
    var guid = guidRef; // This results in `Guid guid = guidRef` and not `ref Guid guid = ref guidRef`
}