Proposal: Allow readonly ref structs to implement interfaces, but disallow boxing them

[ZacLiveEarth]

I'm trying to implement a basic stack-based memory pool that returns Spans to the user of the API. The basic API looks like this...

public static PoolToken Acquire(int length, out Span<T> span);

PoolToken is a struct which would like to implement IDisposable, where Dispose clears the span (if it contains types which have references) and returns the memory to the pool. So, the user can consume the API like so...

using(Acquire(length, out var span)) { /*Do things with span*/ }

Because IDisposable is pattern based, and no boxing is required, this shouldn't violate any of the rules for Span and ref structs.

There may be some other uses for this beyond IDisposable. Other pattern-based code like foreach/IEnumerable may benefit, as may code using pattern matching with generic types like the BoxingAllocations example from Performance Improvements in .Net Core 2.1

Possibly related proposals: #93, #1148

[orthoxerox]

That's what shapes will be useful for. I don't think interfaces can work without boxing, as they are an OO concept.

[benaadams]

I don't think interfaces can work without boxing

Via Generic Constraints (though can't current prevent it in the constrained method 😢 )

[ZacLiveEarth]

@orthoxerox Are you saying that there is something called 'shapes' in the work that subsumes this idea? Can you link to the relevant proposal? I tried to make a best-effort check for deduplication of proposals, but with over 900 issues right now it's complicated. Even a search for 'shapes' in the open issues yields 3 pages of results.

[orthoxerox]

@ZacLiveEarth #110

[ZacLiveEarth]

@orthoxerox Neat. Looks like there's a lot going on in this proposal, it may take me some time to sift through and digest. If it does address this concern, I'll go ahead and close this and/or make a relevant comment on that proposal. Like I said, it'll take some time to go over though.

[VisualMelon]

@benaadams

though can't current prevent it in the constrained method

Would you mind explaining this?

[benaadams]

though can't current prevent it in the constrained method

Would you mind explaining this?

void Method<T>(T value) where T : IEquatable<T>
{
    // What prevents this?
    object boxedValue = (object)value;
}

[scalablecory]

I'd very much like to use this for inlining purposes, e.g.

void Foo<T>(T bar) where T:struct, IFooable
{
    bar.DoFoo();
}

Which is currently impossible with ref structs.

[YairHalberstadt]

Currently I don't believe ref structs can be used as a generic type arguments, so allowing them to implement interfaces would not actually help anything as far as generic constraints are concerned.

For interfaces which are used in a pattern based way, usually you just need to match the pattern, not implement the interface.

As such I don't see what benefit this provides.

[scalablecory]

@YairHalberstadt true, we'd need to open them up for use in generics too.

[YairHalberstadt]

@scalablecory
As @benaadams pointed out, I don't see how that would work. It would also probably require runtime changes.

Besides, I don't believe anything in the spec guarantees that generics with struct type arguments will be specialised, and in certain runtimes Item in the following code may be boxed:

public struct C<T> where T : struct
{
    T Item;
}

[HaloFour]

Even if the runtime didn't box them that method could, and the compiler would lose the ability to enforce the necessary lifetimes to keep the ref struct safe. The example @benaadams posted remains as legal (and unsuitable for ref struct) if T is constrained to struct.

[scalablecory]

@HaloFour definitely not implying struct constraint would solve that. My only aim is to allow ref structs to participate in generics with interfaces, in a way similar to normal struct that would avoid an interface vtable.

[YairHalberstadt]

@scalablecory
But your solution does not deal with the real problems involved. Namely, how on earth can you prevent a ref struct being stored on the heap, once it is used as a generic type argument?

Note this is isn't even about boxing. Here T will be stored on the heap, even if it is not boxed by the runtime:

public class C<T>
{
    T Item;
}

Hence it should be illegal to use a ref struct as a type argument for T.

[scalablecory]

@YairHalberstadt

But your solution does not deal with the real problems involved.

My example is not intended to be a solution to @ZacLiveEarth's request. I've provided another use case in favor of allowing interfaces on ref structs.

I think if we are to allow interfaces on ref structs, we'd want to enable all the features (where appropriate for ref) that interfaces currently enable. The current inability to write any generic code with them is unnecessarily limiting, and is low-hanging fruit to enable some very useful code.

Namely, how on earth can you prevent a ref struct being stored on the heap, once it is used as a generic type argument?

I don't think it's as tough a problem as you're making it out to be. The best solution would require a "ref generic", which would be pretty trivial to implement -- all the checks are there already, we'd just turn them on for those args.

[HaloFour]

@scalablecory

So you're proposing a new ref struct generic constraint? That's the only way I could see this working, and that seems like it would be a very limited use case considering these structs couldn't be treated like the interface in literally any other scenario.

[scalablecory]

@HaloFour yes.

[YairHalberstadt]

#2975 goes into this in a lot more detail.