Proposal: allow open types in nameof

[jskeet]

Imported from https://github.com/dotnet/roslyn/issues/15983. Please see that issue for discussion.

Currently to use nameof with a generic type, a type argument needs to be used. Problems:

• It's very odd to require something to be specified within an operand when it has no impact on the result
• It's inconsistent with typeof
• It means that changing a constraint on a type parameter can break uses of nameof entirely unnecessarily

I propose that the exact same syntax as typeof is used. So for example:

class GenericClass<T>
{
    public string X { get; }
}

class GenericClass<T1, T2>
{
    public string Y { get; }
}

These expressions are currently valid, and would stay valid:

nameof(GenericClass<int>)
nameof(GenericClass<int>.X)
nameof(GenericClass<int, byte>)
nameof(GenericClass<int, byte>.Y)

These expressions would become valid, and would have the same respective results:

nameof(GenericClass<>)
nameof(GenericClass<>.X)
nameof(GenericClass<,>)
nameof(GenericClass<,>.Y)

Using the terminology in https://github.com/ljw1004/csharpspec, it may be that all we need to do in grammar terms is to expand named_entity_target to include unbound_type_name, but I suspect it's more subtle than that.

[HaloFour]

IIRC the limitations of syntax with nameof were specifically to avoid having to define new syntax. While addressing open types is perfectly legal in a typeof expression it's not legal elsewhere, and IIRC addressing members of open types is never legal.

Now that nameof is out the door in it's basic form I'd love to see these limitations addressed. Highest on my list is probably being able to explicitly reference an overload. They tossed around some nastiness like nameof(M(default(int), default(bool)) to avoid new syntax in the past, but I'd prefer to see something like nameof(M(int, bool)).

[TahirAhmadov]

What is the purpose of referencing a specific overload in the context of nameof? Wouldn't the name be the same? I get that we'll need it for infoof/methodof/propertyof, but not nameof.

[chrisoverzero]

So that when you refactor by renaming one overload, the reference to the name knows whether to change.

[TahirAhmadov]

@chrisoverzero oh ok, yes that makes sense. I never had such a situation occur. Thinking about it, the rename feature should have the option to rename either the entire group of methods or just the one method. If these methods were named identically in the first place, it was probably for a reason, and renaming should typically apply to all of them. I guess I find it an exceptionally unusual circumstance to need to rename just one overload out of the group to something else.

[alrz]

@HaloFour

the limitations of syntax with nameof were specifically to avoid having to define new syntax.

Checkout the previous discussion on roslyn repo. The parser is already capable of skipping missing types in a type argument list, the language grammar, however, should be updated to allow this.

[HaloFour]

@alrz

Sounds like little reason to not do this, then. But even if the parser couldn't handle this today I'm certainly not arguing that it shouldn't be modified to support it. I was always disappointed in the limitations imposed on nameof.

[alrz]

To be clear,

• should we allow partial type argument lists? e.g. nameof(C1<int, >)
• should we allow nested open types? e.g. nameof(C1<C2<,>>)
• should we allow nested open types with members? e.g. nameof(C1<C2<,>.C3>)

All this would produce the string "C1". So I think none of it should be allowed.

[jskeet]

All three of those are invalid with typeof, so I don't think we need to allow them. Basically, I want nameof for type names to behave as close to typeof as possible.

[paulomorgado]

@HaloFour

nameof(M(int, bool))

Why? Do you expect different overloads of M to have different names?

@alrz

If all those yield the same result, why having them at all? Wouldn't nameofC1<,>) enough?

[alrz]

@paulomorgado I believe you didn't read my comment in its entirety.

[paulomorgado]

Almost, @alrz. Only missed one or two words. 😄

[HaloFour]

@paulomorgado

Why? Do you expect different overloads of M to have different names?

No, but I expect the IDE to be able to know when to update nameof expressions for overloaded members, which it currently can't do.

Say you have two methods called M. You refactor one to have a different name, Foo. None of the nameof(M) expressions are updated because the IDE has no idea if they refer to the M that is being renamed or the M that isn't. Then rename the other M to Bar and all of the nameof(M) expressions are changed to nameof(Bar).

[paulomorgado]

@HaloFour

No, but I expect the IDE to be able to know when to update nameof expressions for overloaded members, which it currently can't do.

Say you have two methods called M. You refactor one to have a different name, Foo. None of the nameof(M) expressions are updated because the IDE has no idea if they refer to the M that is being renamed or the M that isn't. Then rename the other M to Bar and all of the nameof(M) expressions are changed to nameof(Bar).
I'm aware of that

But if that is ever allow on nameof I would like to see it allowed on overload resolution in cases like this:

void M1() { ... }
int M1(int I) { ... }

void M2(Action a) { ... }
void M2(F<int, int> f) { ... }


M2(M1());
M2(M1(int));

[jnm2]

@paulomorgado Let's start simple, but yes I agree.

For now all I want is to be able to start using open generic types. That's by far the most common and important use case and I don't want anything to postpone that.

[gafter]

It is still legal to name a method nameof, so we would need to define (and implement) the semantic meaning when open types appear in expressions.

[MadsTorgersen]

One issue I remember us dodging with the current restrictions is when you "double dot":

class C<T> where T : D
{
    public T P { get; }
}

nameof(C<>.P.X) // Allowed for which names X?

While it is clear that all C<> have a P, what happens when the omitted type parameter T starts showing up as the type of things? Do we

1. Allow all names present in the constraints of T?
2. Allow just the names in object?
3. Disallow dotting off such things altogether in nameof?

If we were to go down this route, I'd be in favor of 3. 1 gets complicated (what if T occurs in its own constraint?), 2 is useless (just use object itself).

[qsdfplkj]

In case a T : D then nameof(C<T>.P.X) cannot be replaced with nameof(C<>.P.X) as T is unspecified. The compiler should assume T is D and only when D has a X nameof(C<>.P.X) is equivalent to nameof(C<D>.P.X) otherwise you need to specify the generic type parameter to access X.

But in case I need nameof(C<T>.P.X) I can also use nameof(T.X)

[Rekkonnect]

C and C<> are completely distinct types, and not interchangeable. The one has an arity of 0, and the other has an arity of 1.

If D has any visible member named X, assume that this is used. Even if a derived type uses new or overrides it, the name is the same, which doesn't matter in nameof. Therefore this would be a legal case that could be supported.

[jnm2]

Language design meeting November 6th:

We have sympathy. It feels like a corner that's cut. But it's quite expensive to implement, and has semantic dark corners (List<>.First.Foo).

Conclusion

Not now.

(https://github.com/dotnet/csharplang/blob/master/meetings/2017/LDM-2017-11-06.md#roslyn-20450)

If the community addressed the "expensive to implement" part and we went with Mads' option three above, preventing the semantic dark corners, why would you say no?

(I agree with Mads' choice. Double dotting is vanishingly rare; no one will miss it with open generics. The rule unblocks a desirable use case, desirable both for very practical reasons and for ideological satisfaction.)

@alrz has already implemented dotnet/roslyn#20450.

[Joe4evr]

Since I don't see an answer at first glance, what is the expected result of, e.g. nameof(List<>)? Because just yesterday I got into a situation where nameof on an open generic type would've been really useful, but depending the expected result it might not have made a difference.

[jskeet]

@Joe4evr : As per the original comment, the result of nameof(List<>) would be the same as nameof(List<int>), i.e. List.

[alrz]

and has semantic dark corners (List<>.First.Foo).

The current implementation has already some semantic (dotnet/roslyn#20600) and syntactic (#911) dark corners. You can just add open types to that list as another corner.

BTW dotnet/roslyn#20450 already handled that case. See NameOfTests.cs#L1355

[Joe4evr]

@jskeet Ah. Yeah, that wouldn't have worked for my usecase (I needed it to be "List`1").

[yaakov-h]

I would think that if you have any T-returning properties or fields in Thing<T>, you could not traverse through them when using open types.

For example, I should be able to do nameof(IEnumerator<>.Current), but not nameof(IEnumerator <>.Current.Foo).

However if there is a constraint, then you could in theory traverse the constraint. i.e. given:

interface IFoo
{
    string Name { get; }
}

class Bar<T> where T : IFoo
{
    T Baz { get; }
}

I should be able to do nameof(Bar<>.Baz.Name).

Looking briefly at the tests @alrz posted above, this seems to be the approach taken in that pr.

[gafter]

Does the PR include proposed name lookup rule specification changes to justify the behavior?

[alrz]

No, there was no specification to follow at the time and the PR was closed pending LDM decision.

[jnm2]

If a class has a recursive generic constraint, you must write a dummy implementation of the class in order to use nameof. Just hit this in real life.

throw new InvalidOperationException($"... {nameof(AggregateRoot<ThisShouldNotBeNecessary>)} ...");

private sealed class ThisShouldNotBeNecessary : AggregateRoot<ThisShouldNotBeNecessary>
{
    public override ThisShouldNotBeNecessary Clone()
    {
        throw new NotImplementedException("This should not be necessary.");
    }
}

public abstract class AggregateRoot<TThis> where TThis : AggregateRoot<TThis>
{
    public Id<TThis> Id { get; }
    public abstract TThis Clone();
}

public readonly struct Id<TRoot> where TRoot : AggregateRoot<TRoot>
{
    public int Value { get; }
}

sharplab.io

It's a parody of the fact that it's meaningless to specify generic type arguments anyway.

[yaakov-h]

@gafter any chance the LDM could revisit this?

Considering that there are two PRs for implementation (dotnet/roslyn#4907, dotnet/roslyn#20450), it doesn't seem like it's as expensive to implement as the LDM originally suggested.

[gafter]

@yaakov-h Since the language spec doesn't have rules for looking up members in open types, we do not yet have a good spec for the meaning of the proposed construct.

[Rand-Random]

Any progress on this issue?

[jnm2]

There might be. I'm currently quarantining because of possible exposure to covid and this is one of the next things I want to spec. Got a warm reception from a couple of LDM members (which is not a promise of anything).

[FstTesla]

Can this proposal can be revived?

[Rekkonnect]

@jnm2 should be over the quarantine by now I hope

[jnm2]

Yes, good to be reminded. I put it on my calendar to finish the draft proposal.

[jnm2]

Making some progress.

[EtiTheSpirit]

I currently require accessing some static abstract members via reflection, and for this reason using nameof is especially important due to the fact that my library is currently in its alpha phase and things are frequently getting moved around and renamed. These members follow the TSelf design pattern (interface IPersistent<out T> : IPersistent where T : IPersistent<T>).

My current workaround is to create a static class with const fields which evaluate the nameof expressions using a private dummy class which implements the interface. Of course, this is not only wasteful, but it also harms my code's cleanliness by adding unnecessary clutter.

I am very hopeful that this will be merged soon. It is not very fun to deal with.

[jnm2]

Championed proposal being scheduled for LDM soon: #8480