Consider silly cyclic assignment in scoped variance

[jjonescz]

No description provided.

[jaredpar]

I don't think it's so much that it allows silly cyclic assignment as it's just a basic type system violation. Consider that it allows you to do things like:

interface I1 {
  ref int M(); 
}
struct S {
  int field;
  [UnscopedRef] ref int M() => ref field;
}

This is a similar case where introducing [UnscopedRef] in the implementing type leads to lifetime violation.

[jjonescz]

Yes, but that example is already covered by the existing rules and is an error today (I fixed it so S actually implements I1). Those rules are

• Or both of these are true:
  • The method returns a ref struct or returns a ref or ref readonly, or the method has a ref or out parameter of ref struct type.
  • The method has at least one additional ref, in, or out parameter, or a parameter of ref struct type.

This new bullet point

• The method has a ref or out parameter of ref struct type with a mismatch of adding [UnscopedRef] (not removing scoped).

is only necessary because of the silly cyclic assignment.

[jjonescz]

Discussed offline and it's not clear why the paragraph starting with

The compiler will report a diagnostic for unsafe scoped mismatches across overrides, interface implementations, and delegate conversions when:

is in the speclet in the first place.

In other words, it seems that adding [UnscopedRef] or removing scoped should always be a mismatch error without exceptions. cc @cston

We should also investigate this sentence in the light of ref structs being allowed to implement interfaces:

The rules above ignore this parameters because ref struct instance methods cannot be used for overrides, interface implementations, or delegate conversions.