Champion: by value vs `in` overload tiebreaker (15.6, as a 7.2 bug fix)

[gafter]

• Proposal added
• Discussed in LDM
• Decision in LDM
• Finalized (done, rejected, inactive)
• Spec'ed

Based on a suggestion by the LDM, we propose to add the following overload resolution tiebreaker in some future version of C#.

Two applicable methods can have identical parameter types, but differ in argument ref kind. This can occur when the ref kind of one is by value, but the other is in. For example, for the methods

void M(in int x) {}
void M(int y) {}

These would be ambiguous at the call site

M(expr);

Proposal (was implemented in 15.6):

We propose a new tie-breaker: if there is an ambiguity and there is no in at the call-site, then the byval overload wins.
This tie-breaker comes after existing tie-breakers.

Alternative proposal:

We propose a new tie-breaker as follows:

• If the expression is an lvalue, we bind to the overload with an in parameter.
• Otherwise, we bind to the overload with a value parameter.

Because it is not clear how valuable this tie-breaker would be, we are deferring it to some future time when we can judge the impact of ambiguities of this sort.

In the meantime, users can explicitly select the desired overload by using a named argument, an explicit in at the callsite, or by changing the declarations of the methods to be sufficiently different.

LDM

• https://github.com/dotnet/csharplang/blob/master/meetings/2017/LDM-2017-12-04.md#in-vs-value-parameter-ambiguity

[HaloFour]

I don't believe that it's mentioned elsewhere on this repo (e.g. #38) or that the LDM notes have been published yet, but the in parameter modifier replaces the previous readonly ref modifiers, correct?

[bbarry]

Why not:

• If the expression is an lvalue, we bind to the overload with an in parameter.
• If the expression is not an lvalue, we bind to the overload with a value parameter.

Since all lvalues are rvalues, expressing the rule as a combination of the two is potentially ambiguous.

[gafter]

@HaloFour Yes
@bbarry Yes

[4creators]

@4creators Yes

@4creators with regard to in keyword use No

IMO in keyword used instead of ref readonly is an unfortunate choice

[alrz]

IMO in keyword used instead of ref readonly is an unfortunate choice

Since in is now allowed at the call-site I think it's the least harmful choice -- passing in arg to readonly ref param would be unexpected. allowing both is always possible though, perhaps it could be reconsidered when we have readonly parameters.

[tannergooding]

I commented this here: dotnet/roslyn#22387 (comment)

I am explicitly talking about the case where:

• Today a user is consuming MyMethod(MyStruct val) from v1 of MyLibrary.
• I want to take advantage of ref readonly, but do not want to break back-compat in v2 of my library

I cannot add MyMethod(in MyStruct val) because this forces users to upgrade and explicitly specify in at all callsites. They have no mechanism of staying on the previous byval overload if they want to upgrade/recompile (possibly to take advantage of other new features) but are not ready to switch over to the new overloads.

So, in order to take advantage of the feature I have to:

• Use extension methods
• Use an API with a different name (ex: MyMethodRef(in MyStruct val)), etc.
• Something else

This hurts discoverability of my APIs, increases the number of items displayed in intellisense, makes quick-fixes from the IDE more difficult, etc.

Basically, I feel like not providing this in v1 is going to be a significant pain point for existing library authors who are wanting to upgrade to this feature. Authors shouldn't have to be tweaking the order arguments are passed (which may have been "optimized" for an underlying calling convention), the names of arguments (which may cause more changes required on their end or the consumers end),
etc.

[alrz]

@tannergooding So in that case I think in arguments wouldn't be needed?

And I think that's not a good idea that they are optional either, for example, you might specify in for just one of arguments and get the desired overload (at the time) that happens to have other in parameters. the single in makes it like other arguments are passed by value.

void M(in int i, in int j) {}
void M(int i, int j) {}

M(in i, j); // not ambiguous!

Perhaps we should require "all or none" of ref readonly arguments to be passed via in or we just have the tiebreaker from the beginning.

PS: this relates to #476 which propose the same for return types.

[tannergooding]

@alrz, I believe the current stance is (but I may be wrong):

• void MyMethod(MyStruct val) passes val by value
• void MyMethod(in MyStruct val) passes val by reference and ensures it is readonly

If you only declare void MyMethod(MyStruct val), then you just call it as MyMethod(val)

If you only declare void MyMethod(in MyStruct val), then you can call it as either:

• MyMethod(val)
• MyMethod(in val)

If you declare both void MyMethod(MyStruct val) and void MyMethod(in MyStruct val) then calling

• MyMethod(val) is "illegal" and the compiler will throw an ambiguity error
• MyMethod(in val) is "legal" and the compiler will call the ref readonly overload

This means that if you declare both, there is no way to call the "pass by value" overload. This means that adding the new overload is a breaking change and it forces users to modify their code in order to recompile.

The known "workarounds" are:

• Reorder the method parameters so they are no longer ambiguous
• Give the method a different name

I don't think this is a good plan and believe it will largely prevent adoption of ref readonly in existing libraries (possibly including CoreFX, although I don't know the plans there, if any).

I don't think that this is something that is easily fixed post initial release either.

For example, imagine you have a new library and you only expose void MyMethod(in MyStruct val). This means users are allowed to do MyMethod(val) and it will still call the ref readonly overload.

The compiler then decides that not being able to call the "pass by value" overload (if one exists) is a problem and they make it so that, on ambiguous matches the "pass by value" overload is called.

Now say you have some customers who cannot call the ref readonly overload because they are using a language that doesn't support it. So you decide to add a "pass by value" overload for them. However, due to the decision to change the semantics post initial release, adding this new overload will cause any downstream consumers who recompile and that were using the ref readonly overload to now consume the "pass by value" overload (depending on how you wrote the overload, this could potentially cause a drop in performance or more work for the JIT to inline the call).

As such, I think the only "safe" thing to do (so that it is not a breaking change to add a ref readonly overload when their is an existing "pass by value" overload, or vice-versa) is to require in to always be specified at the callsite. The downside is that it is more difficult to use the feature.

[alrz]

This means that if you declare both, there is no way to call the "pass by value" overload. This means that adding the new overload is a breaking change

Here, even though we have an explicit way to "select" the overload via in. the fact that it's an "error" otherwise makes it a lot less useful.

[VisualMelon]

I must confess complete confusion why - especially given that in has been tentatively selected as the keyword of choice - there is any support for not requiring the keyword at the call site. So very much misery can be mitigated by making this a requirement (which would be in concert with other features already present in the language which are of undisputed value).

At best I could only find a suggestion that ref readonly is rather long to type (and so people may be disinclined to use the feature); but even so, this is a feature presented for the purpose of performance, and typing a little more (or even requiring a tad more understanding) can surely be accepted. My apologies if I'm missing something, but I can see no practical value in not requiring the keyword at the call site, and nothing but misery for (particularly) those that have to use and maintain existing APIs which wish to employ it in the future.

I agree with just about everything @tannergooding has just said, and I think it only scratches the surface of how miserable life could be if this ambiguity is allowed. It is (genuinely, I lost sleep over this the last time I reviewed it) unthinkable to me this proposal should go through without requirement of the modifier at the call site. The only thing I am unsure I understand in the previous post by @tannergooding is the remark that "The downside is that it is more difficult to use the feature." - perhaps I am reading too much into this, but I would (really) love to hear what is considered difficult (as opposed to requiring typing, which I consider effort, but by no means difficult) about requiring the modifier at the call site.

I apologise for again being late to the party and not having a clue what is going on, but I do find myself completely bewildered by the proposal, and any polite pointers would be greatly appreciated. I believe that readonly refs will be a valuable addition, but it will only be used by a few people, and these are not people that I can imagine complaining about having to type readonly ref (let alone in) in the interest of maintainability and confidence in their own code. It has been recognised that this feature is solving an old problem, and as such (just as with the non-nullable reference type proposals) the 'introduction' into existing APIs must be a forefront consideration, and no happiness will come from silently breaking and changing these APIs.

Having 'complex' rules for tiebreakers (which do not tally with existing methods for selecting type-based overloading) is just going to create misery; I don't understand the proposed tiebreakers, they are non-obvious. Optional modifiers at the call site is an abhorrent concept: now there are 2 ways to write the same piece of code (except when it is different) which look different.

I cannot comprehend using parameter names for disambiguation, that won't always work, and even when it does it remains completely ambiguous to anyone reading the code... which is REALLY bad (an explicit cast (which with recent addition to VS is even more obvious) screams that something is afoot). This is not a solution on any grounds, and the mere suggestion that it could be employed frightens me.

This post is now far too long... but again, I must express my absolute disbelief that a non-required (let alone 'optional'!) call site modifier could persist in this proposal.

P.S. I find myself unable to determine the best place to rant about discuss this with regard to the 7.2 proposal, if anyone would be kind enough to direct me to such a place I would again be most grateful; or is Champion "Readonly ref" (C# 7.2) #38 indeed the right place to discuss this?

[gafter]

I must confess complete confusion why - especially given that in has been tentatively selected as the keyword of choice - there is any support for not requiring the keyword at the call site. So very much misery can be mitigated by making this a requirement (which would be in concert with other features already present in the language which are of undisputed value).

@VisualMelon C# 7.2, which includes in parameters, is pretty much done, unless we discover show-stopper fatal issues. This proposal is about a change in C# 7.3.

Where, exactly, in the syntax would you suggest the receiver of a call to an extension method should have the in keyword? Where would it be used by the caller when invoking a user-defined operator in which one or both operands are declared in?