Unexpected behavior of `scoped` keyword with interface implementation

[ThousandCuts-0064]

Version Used:

.NET 9

Steps to Reproduce:

public static class Demo
{
    public static void Show()
    {
        var stru = new Stru();

        Unsafe(ref stru);

        Console.Out.WriteLine(stru.Span);
    }

    private static void Unsafe<T>(ref T stru) where T : IStru, allows ref struct
    {
        Span<char> span = stackalloc char[10];

        "bug".CopyTo(span);

        stru.UseSpan(span);
    }
}

internal interface IStru
{
    public void UseSpan(scoped Span<char> span);
}

internal ref struct Stru : IStru
{
    public Span<char> Span;

    public void UseSpan(Span<char> span) => Span = span;
}

Look at IStru.UseSpan(scoped Span<char> span).
Parameter span has the scoped keyword.
Now look inside Demo.Unsafe<T>(ref T stru).
It is valid to pass a Span<char> that references stack allocated memory to stru.UseSpan because of the scoped keyword.
The issue is that ref struct Stru implements IStru and omits the scoped keyword.
This allows it to capture the span parameter.
Now after I call Demo.Unsafe<T>(ref T stru) I get reference to undefined memory.
It seems wrong given this is not in unsafe context and should be prevented by the ref safe context rules.

Expected Behavior:

The code should not compile.

Actual Behavior:

The code compiles and you can read / write to undefined memory.

[RikkiGibson]

Maybe the scoped interface checks are not accounting for the possibility that the this parameter of IStru can be a ref struct. Normally, if we think the usage of scoped doesn't affect the lifetimes in a particular signature, we don't enforce consistency of its usage.

[ThousandCuts-0064]

Then in the context where a ref struct implements an interface shouldn't scoped be enforced in the implementation because that makes a difference? Otherwise scoped is deceptive. In Demo.Unsafe T is constrained to IStru and is allowed to be a ref struct so you expect there to be no problem in passing span to IStru.UseSpan but someone may omit scoped in the implementation of IStru which leads to this issue.

[RikkiGibson]

Yeah, I am speculating that is the bug. Essentially the interface implementation check looks at the signatures IStru.UseSpan(scoped Span<char> span and Stru.UseSpan(Span<char>) span and saying: the scoped difference is fine, because there was nowhere the span can escape to in the interface method. Which is essentially wrong for the purpose of these checks. This could be because when analyzing the interface method symbol, this is assumed to be reference type (as a variable IStru istru would be).

[ThousandCuts-0064]

Should we tag the issue as a bug then? We can either not allow ref struct to omit scoped in implementation or add a check if this is ref struct don't allow scoped difference. What do you think?

[RikkiGibson]

The latter, basically. We should be consistent with the fact that "insignificant" scoped differences already do not cause errors today. We will simply adjust the logic so that a missing scoped in scenarios like the OP is treated as significant. Essentially indicate this could be a "destination" for a ref escape on the interface method.

For comparison: a scenario similar to the OP, except the implementing type is a class, shouldn't enforce consistent usage of scoped across the interface and implementation parameters.

[jaredpar]

Sigh ... I deeply regret that we tried to be smart with scoped in interfaces like this. It's lead to too many bugs like this. Should've just been strict.

[ThousandCuts-0064]

I can see a use case where an interface method does't have scoped on a parameter but a ref struct implementing the interface has it. This would allow you to pass ReadOnlySpan<T> that references stack allocated memory when you use the ref struct directly. Here is a quick demo.

interface IGood
{
    void Method(ReadOnlySpan<char> chars);
}

ref struct Good : IGood
{
    public void Method(scoped ReadOnlySpan<char> chars) { }
}

I'm curious was this the reason for being smart with scoped in interface?