50 lines
1.5 KiB
Markdown
50 lines
1.5 KiB
Markdown
# 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
|
|
|
|
``` c#
|
|
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)
|
|
|