Add proposal for readonly locals/parameters

[stephentoub]

#188
dotnet/roslyn#115

[alrz]

Would all this be applied for the let shorthand? (from dotnet/roslyn#16182)

// ref local
ref var x = e;
ref let x = e;
// deconstruction
var (x, y) = e;
let (x, y) = e;
(var x, var y) = e;
(let x, let y) = e;
// out var
M(out var x);
M(out let x);
// deconstructing out var
M(out var (x, y));
M(out let (x, y));
// just for clarity
foreach (let x in arr)
using (let x = e)
// ref iterator variable
foreach(ref var x in arr)
foreach(ref let x in arr)
// variable patterns
e is var x
e is let x
case var x:
case let x:
// lambda parameters
(x, y) => {};
(let x, let y) => {};
// deconstructing lambda parameters
((x, y)) => {};
(let (x, y)) => {};

[stephentoub]

// ref local
// ref iterator variable

I've explicitly left ref out of this proposal, as noted in the end section. That's not a comment on whether I believe it should be supported, but that I think ref readonly is its own standalone follow-on feature to this.

// deconstruction
// out var
// deconstructing out var
// variable patterns
// lambda parameters
// deconstructing lambda parameters

I would expect all of these to be supported unless there's a specific reason found they can't be. Basically anywhere you can currently define T local or var local, I would expect you'd be able to use readonly T local or let local.

// just for clarity

I'm not sure what the value to supporting this is.

[alrz]

I'm not sure what the value to supporting this is.

Just to make it more visible and consistent over all let and var locals. I think an analyzer could also suggest to use let in those places. Also, with dotnet/roslyn#16155 we want actually distinguish between foreach (ref var item in arr) and foreach (ref let item in arr). It would be inconsistent we only allow let for ref case.

[svick]

This would have no effect on what the caller of the method is able to pass to the parameter

I take it the intention is that readonly for parameters will have no effect whatsoever on code outside the method? It is not represented in metadata in any way, a method with readonly can override method without readonly and vice versa, etc.

Is is worth pointing this out in the proposal?

[stephentoub]

Is is worth pointing this out in the proposal?

Sure, I'll add a note about it. It would likely need to be reflected in metadata for a ref readonly, but that's not part of this proposal.