Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!
We have nowhere to put a ref readonly result. Ref readonly locals are like ref locals, except that they don't allow mutation of the ref'ed variable.
var x = a[1];
ref readonly var r = ref a[1];
We could have var
infer the readonly
as well. It wouldn't be breaking to add later.
Why do we allow the silent copying of readonly struct values in these new scenarios? Do we like that?
No, but for consistency. People will need to use analyzers already to catch the existing cases. Those analyzers should just have this feature in there as well.
We agree that this is a reasonable feature to have, and the design is right.
Like ref locals, these aren't currently reassignable, but there's no dependence on that. We could change it later. There's then technically room for an extra readonly
in front.
For
MyRefTaker(42);
MyRefTaker(ref MyRefReturner());
ref readonly int r = 42;
ref readonly int r = ref MyRefReturner();
b ? 42 : MyRefReturner()
return ref r;
ref readonly int x = a[1];
Discussion about whether the implicitness is a good thing.
There are other options: require "ref" in arguments, require "in" in arguments. We still want the implicit ref in parameters.
For operators, during overload resolution we ignore the refness.
Let's flip to requiring ref
in argument position. ref 42
and ref x+y
etc are allowed.
(Other small decisions)