Allow creating a tuple of ref structs

[YairHalberstadt]

Tuples are often treated as collections of elements rather than a type in and of themselves by the language. For example see dotnet/roslyn#35695.

They are also very useful when it is necessary to return multiple values from a function.

Tuples are already special cased by the compiler.

For these reasons I think it would make sense to allow creating tuples containing ref structs. The tuples themselves would be considered to be ref structs.

Here are two use cases that I came across today:

(ReadOnlySpan<char> beginning, ReadOnlySpan<char> end) Split(string str, int index) => (str.SubString(0, index), str.SubString(index));

And

var (directory, file, extension) = (GetDirectoryName(path.AsSpan()), GetFileNameWithoutExtension(path.AsSpan()), GetExtension(path.AsSpan()));

[Joe4evr]

The only way this could even be allowed is to duplicate the ValueTuple types to a set of RefValueTuples or something. They also wouldn't be able to implement ITuple because ref structs can't implement interfaces.

[YairHalberstadt]

@Joe4evr

I believe (but am not sure) that ref structs are purely a language concept, not a runtime one, so I don't think that's true.

Of course the language would have to make sure that such a tuple is never boxed or cast to ITuple. I imagine that's doable though.

Alternatively, creating a RefStructTuple should also be perfectly doable.

[svick]

@YairHalberstadt

I believe (but am not sure) that ref structs are purely a language concept, not a runtime one

They're not. For example, if you try to create a regular struct with a field of type Span<T> using Reflection.Emit, you get the exception:

System.TypeLoadException: A ByRef-like type cannot be used as the type for an instance field in a non-ByRef-like type.

[john-h-k]

I believe (but am not sure) that ref structs are purely a language concept, not a runtime one, so I don't think that's true.

No, they are properly runtime supported afaik (at least on core). ByRefLikeAttribute on a struct enforces it, and will prevent it being used as a generic type param or being boxed.

This would require allowing ref structs to be generic type params with a constraint like where T : ref struct i believe

[BrandonKoerner]

where are we with this?

[huoyaoyuan]

ref field is considered by the runtime. There's no action to where T : ref struct now.

[huoyaoyuan]

Update: where T : allows ref struct is coming for C# 13. However, there still lacks a feature to make the containing struct ref struct when either of type argument is ref struct.

[AlexeiScherbakov]

It will be usefull for string.Create. After implementing this feature FastAllocateString can be changed to private from internal

Example - dotnet/runtime#30175

[alexis-idigo]

Returning tuples from function (typically with 2-3 elements max) is a really great way to write cleaner and easier to read code>
Function outputs are immediately visible, instead of hidden as out parameters mixed in the parameters list (where? at the end? in the middle if got optional parameters?).

Ex:
(int closest_index, int under_over) Search(float searched, ... other parameters);
vs
int Search(float searched, ... other parameters, out int over_under, ... optional parameters);

That's excellent.

However, NOT Being able for a returned tuple element to be of type ref readonly T just break this nice goal.
Without this support, we have to choose either :-( :

• inconsistent functions interface depending on if a returned type is ref readonly
• give up on returning tuples for an interface that have some such tuples as return

I understand this would require some special treatment, but would ensure consistency in the langage and the source code we can write.

Keeping the language consistent is imho important, else it's hard to understand/use, both for newcomers and experienced programmers.
Hoping this will be considered.

[alexis-idigo]

I'm another one interested in this.
Else need to add lot of boiler plate, either defining special struct/record or ValueTuple.

[MaxMahem]

Something like this should be/is possible in C#13.

public ref struct RefTuple<T1, T2>(T1 item1, T2 item2) 
    where T1 : allows ref struct
    where T2 : allows ref struct
{
    public T1 Item1 = item1;   
    public T2 Item2 = item2;
    
    public void Deconstruct(out T1 item1, out T2 item2)
    {
        item1 = this.Item1;
        item2 = this.Item2;
    }
}

[jaredpar]

Yes that specific type is possible in C# 13 but the language won't recognize it and it would be challenging to do so. Consider for a minute the following example:

(T1, T2) TupleMe<T1, T2>(T1 p1, T2 p2)
  where T1: allows ref struct,
  where T2: allows ref struct => (p1, p2);

This would necessarily end up returning a tuple of RefTuple. That is true even when it was invoked with normal types like TupleMe(1, 2). That would likely be surprising to customers. Further it would mean that adding allows ref struct was a binary breaking change in more scenarios. That's not a blocker but likely a bit surprising.

[FaustVX]

Even without introducing a new RefValueTuple struct, is it possible to enable the use of immediatly-deconstruted tuples with ref struct values. I'm not an expert in the Roslyn compiler, but I'm confident enougth that it can detect this pattern and lower it to simple assignments.

• Used in Ctor:

ref struct MyStruct
{
  Span<int> _a, _b;
  public MyStruct(Span<int> a, Span<int> b)
  => (_a, _b) = (a, b);
}

• Used when Swapping 2 values

ref struct MyGame
{
  Span<int> _currentGeneration, _nextGeneration;
  void Update()
  {
    // ...
    (_currentGeneration, _nextGeneration) = (_nextGeneration, _currentGeneration);
    // ...
  }
}

[jaredpar]

It's possible but would be a language change. Today the compiler is allowed to assume the behavior of the ValueTuple<...> types. Essentially it has assumptions about what the constructors, fields, deconstruction, etc ... does. In the case the langauge spec says "use member X for tuples" and the compiler knows the member is side effect free, it is free to omit that during code gen and emit the more straight line code.

But this is done in the context of the language validates the use of ValueTuple<...> is correct. That would fail here as ref struct are not supported. The language would have to change to say it would work even if the types didn't validate ... I'm guessing LDM would push back on that.

[MaxMahem]

I don't think this does exactly what you want, but I found it a "good enough" solution for many of my use cases.

void ProcessEmail(ReadOnlySpan<char> input) {
    string user = input.Divide('@') switch {
        ([], _) => throw new FormatException("local part cannot be blank"),
        (_, not "test.com") => throw new FormatException("wrong domain"),
        var (userSpan, _) => userSpan.ToString()
    };
    Console.WriteLine(user);
}

public ref struct RefTuple<T1, T2>(T1 item1, T2 item2) 
    where T1 : allows ref struct
    where T2 : allows ref struct
{
    public T1 Item1 = item1;
    public T2 Item2 = item2;

    public void Deconstruct(out T1 item1, out T2 item2)
    {
        item1 = this.Item1;
        item2 = this.Item2;
    }
}

public static class SpanHelper {
    public static RefTuple<ReadOnlySpan<T>, ReadOnlySpan<T>> Divide<T>(this ReadOnlySpan<T> span, T divisor) 
        where T : IEquatable<T>
        => span.IndexOf(divisor) is var pos and >= 0 
            ? RefTuple.Create(span[..pos],         span[(pos + 1)..]) 
            : RefTuple.Create(span[..span.Length], ReadOnlySpan<T>.Empty);
}

public class RefTuple {
    public static RefTuple<T1, T2> Create<T1, T2>(T1 item1, T2 item2)
        where T1 : allows ref struct
        where T2 : allows ref struct
        => new(item1, item2);
}