LDM Notes for March 4th, 2024

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-03-04.md

Agenda

• Breaking changes: making field and value contextual keywords
• Overload resolution priority

[huoyaoyuan]

Is my understanding correct for overload resolution?

• All applicable overloads are gathered first
• Overloads with highest priority number will be included, others are not considered
• Run the resolution rule on included overloads and make the final decision

[333fred]

Not the right order. This is the final pruning step after all other pruning steps have occurred, not the first pruning step.

[TahirAhmadov]

To clarify:

[OverloadPriority(100)]
void M(int a) { ... }
[OverloadPriority(50)]
void M(object a) { ... }
// [OverloadPriority(0)] - default
void M(string a) { ... }

M(123); // int and object are candidates, keep int because it's higher priority
// or
M(123); // int and object are candidates, int is a better candidate because requires no boxing, priority doesn't matter

M("abc"); // string and object are candidates, keep object because it's higher priority
// or
M("abc"); // string and object are candidates, string is a better candidate because requires no casting, priority doesn't matter

[333fred]

The former in both cases. It is technically before overload resolution (I chose the name because I don't really expect most users to dig into the nitty gritty of applicable function member vs overload resolution; people have generally heard of the latter).

[huoyaoyuan]

Maybe the term "applicable" is not clear.

I'd like to see comprehensive description of the steps, with some example.

[333fred]

I would suggest reading the proposal. It is very explicit on where the change occurs :).

[TahirAhmadov]

We do hear more about people misunderstanding the meaning of value than not, but this could simply be a biased opinion because we only ever hear the complaints.

The "silent majority" probably just never experienced any issues with value, meaning their code doesn't have situations in which the status of value is important. The good news is that this also means that they are unlikely to be against changing value to a contextual keyword.

[TahirAhmadov]

I can't think of a reason to make value a keyword in getters.
BTW were events discussed at all?

[HaloFour]

As in treating value as a contextual keyword within explicit event accessors? A nice to have, but it probably doesn't matter terribly. I assume you're not suggesting also supporting field within those accessors?

[TahirAhmadov]

I meant both. By no means I'm arguing this is a priority, but I thought we may get a "volume discount" if both were done at the same time - plus the benefit of consistency. However, if those are not done, I'm not losing sleep over it at all.

[CyrusNajmabadi]

I can't think of a reason to make value a keyword in getters.

Consistency with field and with how they are treated in setters. Instead of having varying rules, we can just say that they are keywords in properties/accessors, and be done with it.

[RikkiGibson]

I don't think it's obvious that value should always be a contextual keyword in a property accessor. I am not sure I like the idea of making it a contextual keyword within the getter, when actually using it would always be an error.

[TahirAhmadov]

Regarding overload priority, is it possible to add a flag to the attribute to "remove" it from IntelliSense? Or maybe negative value means it's not suggested?

[333fred]

No, it's not. BinaryCompatOnly would have meant that it would never be called from any new compilations. This proposal does not prevent overload resolution from finding the member in some circumstance.

[333fred]

But if you're asking how to hide a member specifically from completion lists, that's EditorDisplayAttribute with one of the various enum options.

[TahirAhmadov]

Oh OK, I meant to write something else but forgot - it would need to be [Obsolete("Don't", true), OverloadResolution(-1), EditorDisplay(Never)] - then it cannot ever be called in new compilations, doesn't show up in completion lists (either by itself or as overload option), and another overload will be picked if possible to allow the program to compile - correct?

[333fred]

No. If you are in obsolete context, you can call that member. It may be difficult to get the compiler to select it, but it is possible.

[TahirAhmadov]

Right, outside of an obsolete context, we're basically "there". Thank you!

[alrz]

Would the user priority only take effect when the call is ambiguous or it would take precedence over the default rules altogether?

void M(object); // with priority
void M(string); // no priority or less

M("str"); // which one does this bind to?

[TahirAhmadov]

My understanding is that M(object) would be called, because lesser priorities do not participate in overload resolution. But don't quote me on this - I hope somebody from LDM chimes in.

[333fred]

The priority is used as a final pruning step during finding applicable members. M(string) would be removed from the set, so it would call M(object)

[alrz]

Would it work for Assert(bool, [CallerArgumentExpression] string = default) to be preferred over Assert(bool)?

final pruning step

I guess it would have been removed from the candidate set by then?

[333fred]

Debug.Assert is one of the intended use cases for this.