# C# Language Design Notes for Sep 27, 2017


***Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!***

QOTD: `in int i = in init(in it);`

We changed our minds to allow and require explicit `ref` for `ref readonly` arguments.

``` c#
const int x = 42;
foo(ref x);
```

In the compiler, the order of things change, which is the most churning fix.

Technically not hard to do.

## Concern 1
Is 'ref' the right keyword? Putting `ref` signals to the caller that mutation may be happening. You need to understand what you are passing it *to* in order to know whether it's safe from mutation.

In other cases, like `return ref x` or `ref readonly r = ref x` the `readonly` is nearby, and it doesn't cause the same concern.

## Concern 2
Also, the `ref` in front of rvalues feels wrong. 

``` c#
Foo(ref 42);
Foo(ref await FooAsync());
```

There's an argument that `ref` is about *how* the value is passed, not about the guarantees of the callee. On the other hand we use both `out` and `ref`, where the only difference is the guarantee.

Compromise position:

Use keyword to pass by ref, no keyword to pass "by value" (really by creating a new local and putting the value in).

Warn (or error) when an lvalue is being passed without the keyword, that could have been passed by ref.

* Is it important to be able to see in the code if something is passed by ref?
* Is it important to be able to see in the code if something is copied?
* Is it important that the parameter passing mode reflects the contract?
* Is it important that the same keyword is used for passing and returning?

Other compromise:
- No modifier: Do you best
- Modifier: Require ref, don't copy

The keyword would be `in`. 

Should it then also be `in` in parameter declarations? A danger is that people misunderstand it for "being explicit" about value parameters, whereas `ref readonly` leaves no such room for interpretation. On the other hand, this may be a case where we'd overoptimize for newcomers to the feature, leaving too much syntax for too little benefit. A bit of education, maybe some warnings, maybe analyzers...

## Conclusion

- At the parameter declaration site, use `in`. `ref readonly` is no longer allowed.
- At the call site, `in` is optional. If it is used, the argument has to an lvalue that can be passed directly by ref. If not, then the compiler does its best: copy only if necessary.
No change to `ref readonly` return signature, or to `return ref`.
No change to `ref readonly int r = ref ...`

We would consider allowing `ref readonly int r = 42;` in the future, but it is only useful once we have ref reassignment.

We could consider a warning for `in` parameters of small types (reference types and built-in value types, maybe), but sometimes you do need that. Better left to an analyzer.

What about ambiguity:

``` c#
M(in int x){}
M(int x){}

M(42); // how do you resolve in direction of value
```

We could deal with this through a tie breaker in overload resolution, but it's probably not worth it. 

If you have an API like that, there's going to be a method overload you cannot call. We could always add it later.

This scenario isn't entirely esoteric: if I want to update my API from value-passing to in-passing, then either:

- I add an overload. Then all existing call sites are broken on recompilation.
- I replace the current overload. The all existing assemblies are broken until recompilation.

Instead, you can add an optional parameter, change parameter names etc. to give another means of distinguishing.



Delegate conversion: No contravariance in the type of parameters, unlike value parameters. THis is because the CLR doesn't know about it. It's similar to the restriction on out parameters.


Conditional: If one of the branches is readonly, the whole thing is readonly. That means that calling a mutating member on it would mutate a copy, *regardless* of whether the actual branch chosen was readonly or not:

``` c#
void M(bool b, in x, ref y)
{
    (b ? ref x : ref y).M(); // M is always called on a copy, even if b is false
}
```

# ref structs

## Syntax

Partial has to keep being the last modifier; ref can for now only be right before `struct` or `partial struct`.

Long term we want `ref` to float freely as a modifier. Just may not get to do the work now.






