1.5 KiB
C# Language Design Notes for Sep 25. 2017
Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!
Ref readonly locals
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.
Conclusion
Let's flip to requiring ref in argument position. ref 42 and ref x+y etc are allowed.
(Other small decisions)