Allow nameof operator to discover the name of indexers

[mburbea]

Currently discovering the name of an indexer is a somewhat complicated procedure.

1. If the property's declaring type is string then name is Chars.
2. If the property doesn't have an IndexerNameAttribute then the name is Items.
3. If the property does have IndexerNameAttribute, then good luck finding it. You have to find any property that has more that 0 parameters as this property doesn't make it into the metadata and can't be discovered by reflection.

I propose that nameof can be used to discover the name of such a property. Consider the following:

public struct MyVector2
{
      public float X {get;set;}
      public float Y {get;set;}

      [IndexerName("Component")]
      public float this[int i]
      {
           get{
                  if (i < 0 || i > 1) throw new ArgumentOutOfRangeException(nameof(i));
                  return i == 0 ? X : Y;
           }
           set{
                  if (i < 0 || i > 1) throw new ArgumentOutOfRangeException(nameof(i));
                  if (i == 0) X = value;
                  else Y = value;
           } 
      }
}
...
Console.WriteLine(nameof(MyVector2[0])); // prints Component.

This will make reflection much easier to work with.

[gafter]

Unlikely, as an indexer doesn't have a "name" from a language point-of-view. It only has a name from the CLR's view.

[bbarry]

wrt reflection, perhaps I've been unusually lucky but this code seems to always return the indexer (it works for the case here as well):

typeof(...).GetDefaultMembers().OfType<PropertyInfo>().Single()

Are there cases of spec compliant compiled C# or VB where that is not true?

[gafter]

@bbarry The reflecction APIs should, as you've demonstrated, be usable to get you information about the underlying runtime structure of the compiled program. That has little to do with the language, however.

[bbarry]

I agree, I was pointing out that perhaps the underlying problem here is not some missing thing in the language but rather discoverability and documentation for the apis.

As you stated indexers don't have names in C#; they are annotated by the default member attribute. Per MSDN:

A property is imported as an indexer (default indexed property in Visual Basic) if the property has arguments and if the name of the property or one of its accessors matches the name specified by the DefaultMemberAttribute. If the DefaultMemberAttribute is not present on the containing type, then the type does not have an indexer. The C# compiler emits the DefaultMemberAttribute on any type containing an indexer. In C# it is an error to manually attribute a type with the DefaultMemberAttribute if the type also declares an indexer.

Maybe some language feature that exposed this a little better would help (I'm not convinced it is a language problem; I think it is a reflection api problem). I don't think making nameof return something that is completely unobvious is a good idea.

[mburbea]

@bbarry, you can always declare other properties default members with the DefaultMemberAttribute.

[gafter]

We are now taking language feature discussion in other repositories:

• https://github.com/dotnet/csharplang for C# specific issues
• https://github.com/dotnet/vblang for VB-specific features
• https://github.com/dotnet/csharplang for features that affect both languages

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing the least recently active language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to https://github.com/dotnet/roslyn/issues/18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

As I pointed out previously, I do not believe this is a feature request we are likely to be willing to act upon.