Allow ref-like arguments to conversion operators in ref-like types

[sharwell]

Currently the following is not allowed:

ref struct RefTypeB
{
  public RefTypeB(ref object obj) { ... }
  public static explicit operator RefTypeB(ref object obj) => new RefTypeB(ref obj);
}

CS0631: ref and out are not valid in this context

It would be helpful if limitation was removed, opening the door for the following declaration:

T value = ...;
Span<T> singleElementSpan = ref value;

This change would improve the ability to create data processing APIs that perform well for zero-, single-, and multi-element collections. See dotnet/roslyn#22580.

[YotaXP]

Doesn't this defeat the purpose of ref, by setting the left hand side of the assignment to a new object?

[sharwell]

@YotaXP Expanding on what I wrote, you could do the following:

T value = null;
Span<T> singleElementSpan = ref value;
singleElementSpan[0] = new T();
Assert.Same(singleElementSpan[0], value);

[bbarry]

@YotaXP ref-like types are to be subject to basically the same restrictions that a current ref variable has (I think they should be exactly the same, but that might prove difficult to specify in a way that doesn't break compatibility somehow). It should be OK to convert between them via some method calls involving wrapping/unwrapping the ref object in some ref-like struct.

new RefTypeB(...) here would be a stack allocation instead of a heap object.

[jcouv]

Tagging @VSadov

[omariom]

I'd like to be able to do this:

ref struct HigherLevelMessage
{
    ref LowerLevelMessage message;

    public ctor(ref LowerLevelMessage message)
    {
        this.message = ref message;
    }
}

Will it be possible?

[ufcpp]

Will the ByReference struct be public?

[VSadov]

We discussed some support for wrapping single variable into a span. The issue gets pretty complex when you need to ensure life times.

It seems simple - if you wrap a local, then the resulting span value cannot leave the local's scope, if you wrap a heap location, then it can escape anywhere.

Where it becomes a problem is when ref parameters/returns/local are involved.

• Can I wrap a ref parameter in a span and return it back to the caller? What if it was passing me a reference to a local?
• If I pass a reference to a local to a method and it returns back a span, should I consider a possibility that the span wraps one of my local?
• if the answers to both cases above are "No" (and that is the case right now), then how the proposed Span<T>(ref T obj) could work?

Span<T>(ref T obj) or similar helper cannot be treated as ordinary method, since it breaks the established expectations.

We may need a special language feature that specificaly "takes a ref and wraps it in a span", and we will track result as not escapable, unless we are sure the input ref was a heap ref.

Basically - this functionality may be introduced, but that would not be via a call to an ordinary method/constructor.

[The-Futurist]

@sharwell - This is of interest to me too.

It would be helpful to support struct conversions that allow converting to or from a ref T.

We can already convert ref using numerous methods in the Unsafe static class, so the desire for conversions exists, being able to wrap these in conversions would be neat.

On a similar note we also can't have a property that both returns and accepts a ref T, only getters are supported.

[YairHalberstadt]

@Korporal

We can already convert ref using numerous methods in the Unsafe static class, so the desire for conversions exists, being able to wrap these in conversions would be neat.

These methods are very specifically marked unsafe. There may well not be appetite to make them seem like innocuous conversions.

I think the Unsafe class ought to make you feel a little bit naughty every time you use it.

[The-Futurist]

@Korporal

We can already convert ref using numerous methods in the Unsafe static class, so the desire for conversions exists, being able to wrap these in conversions would be neat.

These methods are very specifically marked unsafe. There may well not be appetite to make them seem like innocuous conversions.

I think the Unsafe class ought to make you feel a little bit naughty every time you use it.

@YairHalberstadt

I'm more or less asking for what the OP asks for here, what one does inside such operators is immaterial surely.

This could also be solved more easily by supporting ref fields but I have no idea if that is likely to happen.

[The-Futurist]

See also this issue.