[Proposal] Syntax for TypedReference

[IS4Code]

Since TypedReference has been once again added to the .NET Standard, there should be better ways of working with it than having to resolve to undocumented keywords, especially since a potentially upcoming high-performance reflection API might be using it.

I propose adding a ref-like syntax that compiles to TypedReference, together with ways to use the mkrefany and refanyval CIL opcodes (undocumented __makeref and __refvalue).

References with generic types aren't always applicable, or need slow workarounds in some cases:

static void Method<T>(ref T r)
{
    Type t = typeof(T);
    if(t == typeof(int))
    {
        r = (T)(object)42;
    }else if(t == typeof(string))
    {
        r = (T)(object)"42";
    }
}

Here, r cannot be directly assigned a value even when we are perfectly sure of its type, and there is no syntax for casting references. If one wishes not to have to box the assigned value, one can use a TypedReference:

static void Method(TypedReference r)
{
    Type t = __reftype(r);
    if(t == typeof(int))
    {
        __refvalue(r, int) = 42;
    }else if(t == typeof(string))
    {
        __refvalue(r, string) = "42";
    }
}

I propose a new, more elegant syntax for specifying TypedReference variables and their operations:

static void Method(ref void r)
{
    Type t = TypedReference.GetTargetType(ref r);
    if(t == typeof(int))
    {
        (int)r = 42;
    } else if(t == typeof(string))
    {
        (string)r = "42";
    }
}

Here, ref void indicates that the parameter is definitely a reference, but with an unknown type (akin to void*). It could be called a "generic reference", and this would also easily explain the limitations of using TypedReference. This code would be compiled to the same CIL as the previous one (maybe with a custom attribute to indicate that ref void is preferred for the parameter).

A generic reference has similar semantics and limitations to a concrete reference (rules for creating variables, passing to and returning from methods, present only on the stack etc.) but with an additional operation of "casting".

(T)r for a ref void r would mean basically the same as __refvalue(r, T) means for TypedReference r. It would represent a reference to a variable with a concrete type, as if the original reference would be declared as ref T r. Therefore, a syntax like ref int i = ref (int)r; should be also allowed.

Creating a generic reference would be an analogue to __makeref, and would have the same rules as normal references do.

__reftype has been used for obtaining the actual type of the reference, and although there could also be a new syntax for it (typeof maybe?), using TypedReference.GetTargetType is sufficient. For checking the type of the reference, a syntax like r is T would be neat, but not necessary.

For compatibility with older code, the original undocumented keywords should be still allowed, but only on variables that are explicitly TypedReference, e.g. __refvalue(r, int) = 0; should not be possible for a ref void r. Generic references and TypedReference wouldn't be mutually compatible, with the only exception of methods that accept or return such references. A way to "cast" ref void r to a TypedReference could be via __makeref(ref r), and something like ref __refvalue(tr, void) for the opposite.

This proposal requires no new .NET API or CLR changes (maybe apart from being able to return a TypedReference, which should have already been allowed).

[bbarry]

What advantage does this have over simply documenting the existing language features?

Specifically:

__refvalue(r, int)

The only thing that is weird about this is that the syntax looks like you pass a type in as a method argument. If it was instead __refvalue<int>(r) we could imagine it being the normal method call to something with the signature:

 ref T __refvalue<T>(TypedReference r);

I don't think the oddity of this syntax is worth the additional complexity of supporting both the current "undocumented" syntax and a future cast syntax (T)r or a generic intrinsic signature like I provided above.

__reftype(r)

This effectively is an intrinsic method of the signature Type __reftype(TypedReference r).

__makeref(ref r)

This effectively is an intrinsic method of the signature TypedReference __makeref<T>(ref T r)

TypedReference itself

Is almost (because it has existed long before the spec) just a soon-to-be normal ref-like type. What would prevent it from being so?

[IS4Code]

1. Consistency with the current ref syntax. At the moment, TypedReference is like a reference except it is really not, as it behaves more like a pointer in terms of its operations and semantics. Using the cleaner syntax, it would be easy to convert existing code to use the "generic" reference with minimal amount of changes. It also hides the fact that there are some specific byref-like types (TypedReference, ArgIterator, RuntimeArgumentHandle) which the programmer might be confused about.

2. Extensibility and elegance. In order to preserve backwards compatibility, the current semantics of TypedReference cannot be changed, maybe except for relaxing some of its limitations (returning it). The keywords that operate on it will still have to have __ in front of them, making the resulting code harder to read and understand (and introducing new keywords could potentially break older code).

It doesn't "unlock" new CLR features, but makes existing ones more usable, clean, and easier to understand. It is harder to explain that "TypedReference describes objects that contain both a managed pointer to a location and a runtime representation of the type that may be stored at that location" than explaining that "ref void represents a generic reference to a variable of any type".

One could also ask why there is int? when we can simply write Nullable<int>, or why there is the tuple syntax etc. - it hides the fact that it is a specific type, and promotes the fact that it it special in some sort.

[mikernet]

Isn't the proper solution here to add better support for casting open generic types so that the object cast isn't necessary?

Furthermore, doesn't the JITter optimize out the object cast in expressions like (T)(object)42 these days if T is the same type as 42? Given this, I think relaxing the requirement to cast to object first makes sense, just have the C# compiler emit it since it is inconsequential and unnecessarily noisy.

[Pzixel]

This proposal makes sense, however, I don't like this ref void r. Void is nothig, you cannot pass nothing as parameter and name it. Please, leave C/C++ alone. I'm completely against adding some features to C# just because C+ does. Considering "well, void* is anything" is a very poor design, do not copy it into the good language. It's probably better to introduce a new type and use it:

static void Method(ref AnyReference ar) ...

[jnm2]

@Pzixel

Considering "well, void* is anything" is a very poor design, do not copy it into good language.

Too late. https://sharplab.io/#v2:C4LghgzgtgPgAgZgARwExIMIFgBQBvXJIlZAVwDsIwAzAUxQBYkBZACjgYCpGAFAewCW5YLQBOASkLECOYkgC+ueUA==

[Pzixel]

@jnm2 god, I have completely forgot about it... Well, still weird, because IIRC with void* method you have to pin your object and pass it, whilst with TypedReference you don't have to.

[benaadams]

Would be nice if flow anaylsis allowed a type check as a type validator; so this was valid

static void Method<T>(ref T r)
{
    if (typeof(T) == typeof(int))
    {
        r = 42;
    } 
    else if (typeof(T) == typeof(string))
    {
        r = "42";
    }
}

However TypedReference is still needed for non-boxing via reflection

[mikernet]

If you're getting into reflecting against generic types, is boxing not the least of your worries at that point? How many use cases would practically benefit from avoiding boxing during reflection calls, and is it worth the cost to implement a new syntax for those few scenarios?

I agree with the flow analysis suggestion though, that would really clean up a lot of code in the projects I work on :)

[benaadams]

If you're getting into reflecting against generic types, is boxing not the least of your worries at that point?

If you are setting a struct's value using reflection SetValue; it cannot be set as you are operating on the boxed value; so cannot change the original. You can instead use a TypedReference and set it with SetValueDirect.

I'm not necessarily agreeing with the proposed syntax; but the existing C# keywords __refvalue, __reftype, __makeref are a bit incongruous with general C# syntax; so it may be nice to have something better here.

[ufcpp]

You can use System.Runtime.CompilerServices.Unsafe to avoid boxing.

static void Method<T>(ref T r)
{
    Type t = typeof(T);
    if (t == typeof(int))
    {
        Unsafe.As<T, int>(ref r) = 42;
    }
    else if (t == typeof(string))
    {
        Unsafe.As<T, string>(ref r) = "42";
    }
}

[IS4Code]

You're right that ref void may be misleading for people not aware of pointers, and if we ignore the void* syntax, there is not much consistency in the proposed syntax. Other candidates for the syntax I have came up with, are ref any (introducing a new keyword where an identifier can be, not a good idea), any ref (still introducing a new keyword but probably unambiguous and consistent with the name of the opcode), ref var (sounds interesting, but adds another complexity and ambiguousness to an already estabilished syntax) and var ref (not bad, but potentially confusing).

[benaadams]

Could just keep it similar without the void

static void Method(TypedReference r)
{
    Type t = __reftype(r);
    if (t == typeof(int))
    {
        __refvalue(r, int) = 42;
    }
    else if(t == typeof(string))
    {
        __refvalue(r, string) = "42";
    }
}

But allow TypedReference to be cast as an lvalue (as per your suggestion), so:

static void Method(TypedReference r)
{
    Type t = TypedReference.GetTargetType(r);
    if (t == typeof(int))
    {
        (int)r = 42;
    } 
    else if (t == typeof(string))
    {
        (string)r = "42";
    }
}

And/Or better would probably be pattern matching with ref types:

static void Method(TypedReference r)
{
    if (r is ref int i)
    {
        i = 42;
    } 
    else if (r is ref string s)
    {
        s = "42";
    }
}