Champion: Name lookup for simple name when target type known

[gafter]

There are three contexts in which lookup of a simple (not qualified) name would benefit from the fallback of looking up the identifier in a target type.

Simple ID expression

When an expression is an unqualified identifier, and lookup fails to find any accessible binding for that identifier, it is treated as target-typed. When the target type becomes available, the identifier is looked up in the context of the target type. If the identifier in that type designates an accessible constant, static field, or static property whose type is that target type, the identifier binds to that member.

Example:

enum Color { Red, Greed }

Color M1() => Red; // OK, binds to Color.Red

int IsRed(Color c) => c switch {
    Red => true, // OK, binds to Color.Red
    _ => false,
};

Object creation expression

When an object creation expression's type is given as an unqualified identifier (possibly with type arguments), and lookup fails to find any accessible binding for that identifier, it is treated as target-typed. When the target type becomes available, the identifier is looked up in the context of the target type (and the rest of the creation expression is bound, like the target-typed new expression). If the identifier in that type designates an accessible type that has an implicit reference conversion to that target type, the identifier binds to that type.

Example:

class Outer
{
    public class Inner1: Outer { }
    public class Inner2<T>: Outer { }
}

Outer M1() => new Inner1(); // binds to Outer.Inner1
Outer M2() => new Inner2<int>(); // binds to Outer.Inner2<T>

Type in a pattern

When the type appearing in a pattern is given as an unqualified identifier (possibly with type arguments), and lookup fails to find any accessible binding for that identifier, the identifier is looked up in the context of the pattern's input type. If the identifier in that type designates an accessible type, the identifier binds to that accessible type.

Example:

class Outer
{
    public class Inner1: Outer { }
    public class Inner2<T>: Outer { }
}

int M1(Outer o) => o switch
{
    Inner1 => 1,          // ok, binds to Outer.Inner1
    Inner2<int> => 2, // ok, binds to Outer.Inner2<T>
    _ => 3,
};
bool M2(Outer o) => o is Inner1;  // ok, binds to Outer.Inner1
bool M3(Outer o) => o is Inner2<int>;  // ok, binds to Outer.Inner2<T>

Design Meetings

https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-09-26.md#discriminated-unions

[gafter]

/cc @agocke @MadsTorgersen

[DaZombieKiller]

So with this, would I be able to do something akin to GetMethod("Name", Public | Instance) without using static System.Reflection.BindingFlags;?

[huoyaoyuan]

Quite useful, but what about the compiler overhead of overload resolution?

enum E1 { EA, EB, EC }
enum E2 { EA, EB }

void M(E1 e, int x);
void M(E2 e, string x);

M(EA, someParameter);

Does this meet the similar overload resolution algorithm when using number literals?

[mattwar]

Greed is the color of money.

[alrz]

Public | Instance

As per current proposal, I think you would need to qualify at least one operand,

GetMethod("Name", BindingFlags.Public | Instance)

In order to omit type for all of them, the operator | itself needs to get target-typed.

[333fred]

That's exactly correct, and we actually brought up the | operator in the meeting when talking about this.

[reflectronic]

[alrz]

I've encountered with an issue with using static,

case IBinaryOperation { OperatorKind: Equals } op:

Equals binds to the class member and produces an error.

For target-typed lookup, would it make sense to alter the spec as follow?

When an expression is an unqualified identifier, and lookup fails to find any valid accessible binding for that identifier, it is treated as target-typed.

The lookup itself would have no information about the context and we'll need to add a new bottleneck to check the validity which is defined as being a constant of a particular type in this case.

[gafter]

@alrz We would need to define a concept of validity for every context in which an expression could appear. I don't think it is worth it.

[alrz]

We would need to define a concept of validity for every context in which an expression could appear.

To avoid that, as a simpler rule, we could say if an identifier is already found but the conversion fails, we treat as target-typed. In other words, it's defined as the fallback conversion iif the source expression is a simple identifier. Then it wouldn't depend on the context.

In the example above, method group fails to convert to enum, so it will be treated as target-typed.

edit: I realized the above might be a breaking change in some scenarios involving overload resolution, candidates that were not applicable becomes applicable and could change program's behaviour.

[gafter]

To avoid that, as a simpler rule, we could say if an identifier is already found but the conversion fails, we treat as target-typed. In other words, it's defined as the fallback conversion iif the source expression is a simple identifier. Then it wouldn't depend on the context.

That would be a breaking change. In an expression such as M(Name, e2, e3), where M is overloaded, there might be some M in the method group whose first argument would not accept the "normal" meaning of Name. But with this new rule that method would become a candidate, and that could change the result of overload resolution. I don't think we should do that.

[alrz]

In a design note there was a consideration to separate out overload resolution in target-typing scenarios to be able to tweak conversions without breaking change. I think this one would be another case where that could help.

https://github.com/dotnet/csharplang/blob/master/meetings/2019/LDM-2019-10-28.md

I think the situation is almost the same as short x = b ? 1 : 2; for target-typed ?: expressions.

[gafter]

I think the situation is almost the same as short x = b ? 1 : 2; for target-typed ?: expressions.

No, this is give a meaning to code that was definitely an error before. There is no breaking change in that case.

[alrz]

No, this is give a meaning to code that was definitely an error before. There is no breaking change in that case.

I was responding to:

That would be a breaking change. In an expression such as M(Name, e2, e3)

Target-typing Name would be breaking as much as target-typing the ternary in M(b?1:2, e2, e3). I think whatever semantic is being used there, can be also applied to names so that the example above with Equals gets target-typed instead of an error.

[gafter]

That would be a breaking change. In an expression such as M(Name, e2, e3)

If Name bound to something before, then it would not be target-typed. If it did not bind to something before, then this was illegal code. Either way, it isn't a breaking change.

[CyrusNajmabadi]

It is the version with a dot that has a syntactic ambiguity.

Yes, i mentioned that below:

Note: while this form has an ambiguity with a?.b i think that's acceptable and we can say in that case you need to write a ? (.b) : (.c)

I'm not saying it's exactly this form. I'm saying i'm willing to champion a form that has no syntactic ambiguity but has some syntactic difference beyond just a simple name. Thanks!

[cytoph]

I have to say, that I don't really get why syntactic ambiguity is so much of a problem here. So meticulously as this topic is approached here, one could argue that properties or fields should also always have a dot in front, when used, to show that they are properties/fields and not class or variable names. But for that kind of ambiguity there is the this or base keyword. So why is that approach not applicable to enum members, too? If the enum member is used only by its name and there is a member, variable or whatever that has the same name, the compiler throws an error and asks to explicitly put the enums name in front of the member name, to clarify what exactly is used in that case (like with CS0229).

Or am I totally missing a point here? 🤔

[Logerfo]

@cytoph I'm afraid that would be a breaking change, since code that already has an enum member identified exactly as some other accessible identifier at the same context doesn't issue a warning today, but will issue with the new compiler.

[cytoph]

@Logerfo Ah, I think I get what you mean.

In the following case (which is perfectly fine and clear with the current compiler, but with the changes I proposed) the compiler wouldn't be able to tell exactly what I want to assign to the variable test (the value of the property Value1 or the enum value Value1). That is what you meant (or at least an example for what you meant), right?

enum MyTestEnum
{
    Value1, 
    Value2
} 

class MyTestClass
{
    public MyTestEnum Value1 { get; set; }

    public void MyTestMethod() 
    {
        MyTestEnum test = Value1; // here would be the problem
    } 
} 

[sab39]

Surely if we want this to be a non-breaking change then it's a no-brainer to pick the non-breaking interpretation, that this new interpretation only applies if the name isn't found any other way. Also the new interpretation should only apply if the enum value name is the entire expression; MyTestEnum test = Value2.Something() would not be valid if the only Value2 in scope is the one in MyTestEnum.

[cytoph]

@sab39 That would also fit the way as it works with properties/fields and variables: If both are named exactly the same, it's always assumed the variable is used, unless of course you specifically use the this keyword. And I think that would be a perfectly fine solution to this topic, too, and it would ensure that there are no breaking changes in existing code. If there's an ambiguity, everything else is picked above the enum member. Only if the enum members name is distinctly identified in the current context, it is used as is.

[gafter]

I think you folks are missing a crucial point. This is not a semantic ambiguity, where we know how to parse the code and just need to do name lookup to decide between one interpretation or another. This is a syntactic ambiguity while trying to parse the code (figure out which punctuation means what). Parsing occurs long before name lookup, and cannot depend on name lookup.

[tuscen]

Hi. Would this work for cases when the outer type is used as a return type?

Consider

public abstract record Result<TR, TE>
{
    public sealed record Ok(TR Value) : Result<TR, TE>;
    public sealed record Error(TE Value) : Result<TR, TE>;
}

Will this proposal allow me to write some thing like that?

Result<int, string> Validate(int value) => value switch
{
    > 100 => Ok(value),
    _ => Error("Some error text")
};

var result = Validate(101);

int val = result switch
{
    Ok(var value) => value,
    Error(var value) => throw new InvalidOperationException(value)
};

[Richiban]

@tuscen I would assume so, since the feature is likely to be built upon the existing target typing rules and return type is considered there. For example, this compiles fine:

public class C 
{
    public object M() 
    {
        return new();
    }
}

[AlexeiScherbakov]

Today "using static" solves this problem. If you have to many "using static" - may be it is a time to split code to different classes? :-D

Also in this thread I see also problem "simplification of generic names when taget type known". This is other than initial problem!

[edward-a]

Today "using static" solves this problem.

No, it doesn't. Consider you initialize GUI tree in code and have HorizontalAlignment and VerticalAlignment enums both having Center entry.

[edward-a]

I think you folks are missing a crucial point. This is not a semantic ambiguity, where we know how to parse the code and just need to do name lookup to decide between one interpretation or another. This is a syntactic ambiguity while trying to parse the code (figure out which punctuation means what). Parsing occurs long before name lookup, and cannot depend on name lookup.

Interpretation-wise, do you care if it's a local variable or a class member (assuming there is no this. prefix)? If not, then i don't see why you would care if it's an enum value. Hope you elaborate.

[agocke]

If we end up making _ a reserved keyword in the language, theoretically I think the _.Name syntax would be viable for this feature.

[aradalvand]

I would very much prefer explicitness in this case — i.e. use a leading dot (a la Swift) to denote "target-typed" for enums.

Makes the rules more straightforward. It also makes things less ambiguous and makes code easier to scan in PRs, etc.

[gafter]

I would very much prefer explicitness in this case — i.e. use a leading dot (a la Swift) to denote "target-typed" for enums.

Makes the rules more straightforward. It also makes things less ambiguous and makes code easier to scan in PRs, etc.

See #2926 (comment) for a discussion explaining why that proposal leads to a syntactic ambiguity.