Proposal: NameOf to have optional parameters.

[AdamSpeight2008]

Proposal: NameOf to have optional parameters.

Currently.
nameof(Microsoft.CodeAnalysis.CodeFixes.CodeFixProvider) = "CodeFixProvider"
(See #3708)

To fix this I propose that we should extend NameOf with optional parameters. , NameOfOptions:= )

NameOfOption Enum

Enum NameOfOption As Integer

  [default] = 0
  fullname  = 1

End Enum

Api signature

NameOf(  obj As Object, Optional NameOfOptions As NameOfOption = Nothing ) As String

Example

nameof(Microsoft.CodeAnalysis.CodeFixes.CodeFixProvider, NameOfOptions:= NameOfOption.FullName )

This would then provide the fully-qualified name.

It provides a compile-time solution, to what (I believe) requires the use of reflection, or explicitly stating the full name as a string literal. Hence introducing a potential bug if it changes namespace or name.

Does not break existing usage because the parameter is optional.

[svick]

In what situations would this be useful?

[AdamSpeight2008]

@svick See #3708.

[leppie]

nameof is a compile time construct, it has no API.

A better solution would be to use pragmas to control the output/options.

[paulomorgado]

That has been largely discussed on Codeplex.

It was even discussed FullNameOf.

[hishamco]

@svick this may useful in `Exception`` when the argument is property path, have a look to this aspnet/WebSockets@208fa4a#diff-2f20d3473af8bc60eee727dd88bbb804R595

[Eilon]

The parameters to argument exceptions are never "property paths" - they are parameter names. Passing in foo.Bar.Baz to an ArgumentException is invalid.

[whoisj]

What is wrong with $"The name is {nameof(value)} and its type is {typeof(value)}, and the type's full name is {typeof(value).FullName}, and {nameof(value)} has a property of {nameof(value.Property)}."?

[hishamco]

@Eilon that's exactly what I mean foo.bar.baz 😄

[Eilon]

@whoisj that's exactly what I recommend people to use.

[whoisj]

@Eilon I know. My comment was towards the original post. 😏

[hishamco]

I don't think so that will applicable for value.Length where value is String

[whoisj]

I don't think so that will applicable for value.Length where value is String

What won't be?

Given void 'MyFunc(string value)'

• nameof(value) == "value"
• typeof(value) == System.String
• nameof(value.Length) == "Length"
• typeof(value.Length) == System.Int32

[hishamco]

@whoisj our intend to display something like foo.Bar.Baz using nameof which is an implementation limitation :(

[whoisj]

@hishamco then I go back to my original statement: what is wrong with $"{nameof(foo)}.{nameof(foo.Bar)}.{nameof(foo.Bar.Baz)}" ?

[hishamco]

Looks good trick 😄

[svick]

@AdamSpeight2008 So this is just a performance optimization of typeof(CodeFixProvider).FullName? That doesn't sounds like it would be worth inventing new syntax to me.

[whoisj]

@AdamSpeight2008 So this is just a performance optimization of typeof(CodeFixProvider).FullName? That doesn't sounds like it would be worth inventing new syntax to me.

I said the same thing, they're not looking for Type.FullName, they're looking for the texted used in the parameter validation. Example:

if (foo.Bar.Baz == null) throw new NullArgumentException(nameof(foo.Bar.Baz));

They want to see "foo.Bar.Baz" returned by the nameof macro, but they're only getting "Baz".

[leppie]

I agree with @svick . Also some syntax sugar for typeof(Foo).Fullname cannot be resolved reliably at compile-time, so there is no optimization to be had.

I pondered during last week on Twitter if something like the following would not be useful (also mentioned by @whoisj):

var i = 0;
typeof(i) j = 1; // here typeof(i) is an alias for the same type as i
Foo<typeof(i)>(); // same here
Console.Write(typeof(typeof(i))); // prints System.Int32

The tiny benefit here is you only need to change the type of i (say to byte or long) and the rest of the code 'refactors' itself. Still not sure if such a benefit is worth it. Would be another story if C# had macros or templates.

[AdamSpeight2008]

@leppie

cannot be resolved reliably at compile-time?

How? Doesn't the compiler currently do type-checking at compile-time, which suggests to me the the fully qualified name is also available..

[leppie]

@AdamSpeight2008 typeof only loads the type token as determined at compile time, fullname would be constant string. Now imagine some AOP process changing something (namespace, type), etc. If something bad happened, peverify will say the type token is now invalid, but with a string, all bets are off. Perhaps this will never happen, but who knows?

[gafter]

Regardless of whether we would ever provide support for getting a fully qualified name (seems unlikely), we would not do it in the way requested here.