Use in for parameters and arguments

[jcouv]

From LDM discussion today:

1. parameters should be declared with in instead of ref readonly

2. plain method call with consider both byval and in candidates, and continue producing an error if ambiguity

3. in at call site guarantees the in candidate is picked and no copy is made

4. async spilling should never make a copy if in (an error should be produced in this case)

This bug is about part 1

Other parts are tracked in #22387

[4creators]

IMO counter intuitive and counterproductive. Pls respect developers past experience and education and do not break intuitive meaning of keywords.

[tannergooding]

I also commented this here: #22387 (comment)

I think there is a sort-of disconnect here on making this feature easy to use and allowing existing code to upgrade to it.

Not requiring the user to specify "in" when the case is not ambiguous makes it easy to use in entirely new code. However, due to requirements/desire to not introduce breaking changes to existing libraries, this also means that people consuming things like CoreFX will be having to attribute "in" a lot anyways.

Additionally, this means that when users do provide new APIs, users moving to the new version of the library will be forced to upgrade their code (they only have the option to disambiguate with "in", otherwise things will fail) which will likely prevent new adoption or entirely prevent the library from providing these overloads in the first place (outside of extension methods so users can manually opt-in, but this also hurts discoverability of those APIs and can lead to other issues when the API requires access to the private members of the underlying type).

[asyncawaitmvvm]

IMO counter intuitive and counterproductive. Pls respect developers past experience and education and do not break intuitive meaning of keywords.

If we can chase useless dead-ends like a compiler switch for nullable references (what next, nullable nullables?), we can make provision to keep our CS teachers from having to tell students that ref readonly is the logical opposite of out. ref readonly tells you nothing of the direction that the readonly behavior applies; so much for the "intuitive meaning of keywords".

Considering that this is C# and not [your forgotten dying prior language that you mysteriously aren't using anymore] we should use in as the exact opposite of out. C# uses in for the foreach statement and co/contra-variance, the latter of which most C# programmers have never heard or cared about. Therefore we have no "past experience and education" to break in the first place.