Proposal: fullnameof operator

[dsaf]

Migrated from: dotnet/roslyn#14474 and dotnet/roslyn#7973

A well-know one, not much to add.

Doing this currently which is not amazing:

public static class Extensions
{
    public static string fullnameof<T>() => typeof(T).FullName;
}

using static Extensions;

Console.WriteLine(fullnameof<SampleClass>());

[jnm2]

If we do this, fullnameof should return the C# language name, not the CLR type name (to the extent that they differ). That is the current philosophy behind nameof and I see the value. For example, Foo not Foo`1 or Foo`1[System.Int32].

In other words, it should return what you type in C# to refer to the object, not the CLR representation.
This matters with nested classes because in C# you don't write Namespace.ContainingType+NestedType; you write Namespace.ContainingType.NestedType.

[mwpowellhtx]

@jaredpar I'd expect it to be consistent with nameof which returns the alias name IIRC. nameof(int) is not allowed, either.

Is System.Int32 the same as int in this instance? I don't know. Assuming a less contrived illustration, of course.

[jaredpar]

My intuition would lean more towards making fullnameof(somealias) a warning / error. The logic being that if you wanted the simple name then you can use nameof. Using fullnameof here means you likely didn't realize it was an alias or mistakenly thought it would apply to the underlying type

[foxesknow]

Does it have to return a string? Why not return a struct with various properties. For example:

Console.WriteLine(fullnameof(Example).Alias);  // Example
Console.WriteLine(fullnameof(Example).Name);  // Int32
Console.WriteLine(fullnameof(Example).LanguageName);  // Int

[IanKemp]

Does it have to return a string? Why not return a struct with various properties. For example:

Console.WriteLine(fullnameof(Example).Alias);  // Example
Console.WriteLine(fullnameof(Example).Name);  // Int32
Console.WriteLine(fullnameof(Example).LanguageName);  // Int

Because that's unnecessary complexity. If you want that information, use reflection.

[KalleOlaviNiemitalo]

Current behavior of nameof:

namespace Demo;
using Hah = System.Int32;

class @new
{
    const string name1 = nameof(@new); // means "new", not "@new"
    const string name2 = nameof(Hah); // means "Hah", not "Int32"
    const string name3 = nameof(System.Func<int>); // means "Func", not "Func`1"
    const string name4 = nameof(@new.Finalize); // means "Finalize", not "~@new"

#if false
    const string bad1 = nameof(operator +); // error CS1041
    const string bad2 = nameof(op_Addition); // error CS0571
    const string bad3 = nameof(~@new); // error CS0119
    const string bad4 = nameof(~@new()); // error CS1955
#endif

    public static @new? operator +(@new? a, @new? b) => null;

    ~@new() { System.Action act = this.Finalize; }
}

Direct calls to Finalize methods are blocked by error CS0245, but this.Finalize is a valid expression convertible to a delegate, so it seems OK that the value of a nameof expression can be "Finalize" as a C# language name.

The "new" vs. "@new" distinction makes me wonder whether fullnameof(global :: System . Int32) should be "global::System.Int32" or just "System.Int32". It should surely omit unnecessary whitespace, though. Inspired by dotnet/csharpstandard#193.

[jjvanzon]

I feel uneasy promoting my own framework here, but I made something for this a long time ago. It isn't perfect, but it will handle many common cases. You can call:

ExpressionHelper.GetText(() => myVariable.MyList[i].MyProperty);

And get "myVariable.MyList[i].MyProperty" out.

It won't cover full type names, though. I had something for that too, but I never ported it to my current code base.

https://github.com/jjvanzon/JJ.Framework/blob/master/Framework/Reflection/ExpressionHelper.cs
https://github.com/jjvanzon/JJ.Framework/blob/master/Framework/Reflection/ExpressionToTextTranslator.cs

[jnm2]

@janjoostvanzon That's really cool! Now if only it was a compile-time constant and could be used in an attribute...

[jjvanzon]

@jnm2 That's what I thought when I made it. That would give better performance, even though I did try to make it perform well without sacrificing reliability. Still it cannot be faster than a literal string.

[alrz]

@dsaf

There is a proposal to make typeof(T).FullName a compile-time constant (dotnet/roslyn#10972). Does that cover your use cases?

Also #522 suggests to add a shorthand for nameof(Class.Method), e.g. $Class.Method, I'd added to that that we can use [email protected] to produce a string as it appeared in the source (#522 (comment)).

[jehrenzweig-captionhealth]

dotnet/roslyn#10972 has been marked "Closed as not planned".

[dsaf]

@alrz not really as it would be nice to be able to refer to sub-namespaces and members as well (yes, I remember dotnet/roslyn#1653).

I am mostly after shortest possible syntax but compile-time evaluation is also important.

[alrz]

it would be nice to be able to refer to sub-namespaces and members

[email protected] would allow that too, yes it does require to spell out all required parts but I don't think we can make it any shorter without losing flexibility.

[Meai1]

This stuff is ridiculous, an extra keyword just for something small like this? just add a method like Class.fullnameof

[HaloFour]

@Meai1

The point of it being a keyword is that it could be used as a constant. Invoking a method on the Type class doesn't result in a constant string and thus can't be used in something like an attribute.

I believe there is a separate proposal for having the compiler consider certain expressions on typeof(T) as constants, e.g. typeof(Foo).FullName.

[Meai1]

ok but this really sounds more like a problem about c# attributes. Why else require all these new keywords

[HaloFour]

@Meai1

The arguments used in attributes are required to be constants and embeddable directly in the assembly metadata. That is a limitation of the CLR and not specifically of the C# language. When the CLR actually instantiates the attribute it expects that the embedded constant matches the type of the constructor parameter or property so the C# compiler can't embed any alternatives, let alone something that represents an expression to be evaluated at runtime. The best the C# compiler could do is to introduce a form of constant expressions (constexpr) which could be evaluated at compile time and their result directly embedded.

[rummelsworth]

This would be mighty convenient in some cases, especially when defining an EventSource subtype.

I'm currently doing this:

        // I'm repeating the full namespace in each case, even though I don't strictly need to, for better safety if/when refactoring moves things around.
        [EventSource(Name =
            nameof(Company) + "." +
            nameof(Company.ProductUmbrella) + "." +
            nameof(Company.ProductUmbrella.Product) + "." +
            nameof(Company.ProductUmbrella.Product.Feature) + "." +
            nameof(Company.ProductUmbrella.Product.Feature.Module) + "." +
            nameof(Company.ProductUmbrella.Product.Feature.Module.ETWEventSource))]
        public class ETWEventSource : EventSource
        {

I'd be delighted to be able to do this:

        [EventSource(Name = fullnameof(ETWEventSource))]
        public class ETWEventSource : EventSource
        {

[IanKemp]

This should work for namespaces too!

I.e. fullnameof(Full.Namespace.Name) = Full.Namespace.Name

[CyrusNajmabadi]

If we do this, fullnameof should return the C# language name, not the CLR type name (to the extent that they differ). That is the current philosophy behind nameof and I see the value. For example, Foo not Foo1 or Foo1[System.Int32].

How does this work with generics?

[npodbielski]

This would be most usable in Obsolete attribute.
[Obsolete("use "+fullnameof(NewClass.NewMethod)+" instead.")]
For now this is necessary to use
[Obsolete("use "+nameof(NewClass) +"." + nameof(NewClass.NewMethod)+" instead.")]
Which is a really tiresome for few dozens of members.

[hez2010]

Why not reuse the current operator we already have?
Instead of fullnameof(Foo), we can allow passing constant args to nameof. For example, nameof(Foo, fullName: true), or even nameof(Foo, true)

[colejohnson66]

I'm not a fan of nameless optional booleans, and nameof(Foo, true) fits that. Because now nameof(Foo) and nameof(Foo, false) mean the same thing. nameof(Foo, fullName: true) would work, but it's too wordy, and doesn't address the optional behavior of it.

[KieranDevvs]

Because now nameof(Foo) and nameof(Foo, false) mean the same thing.

What's wrong with that? Its kinda the whole point of optional arguments. And if you dont like it being nameless, then fully qualify it as @hez2010 already did: nameof(Foo, fullName: true)

[TheBrambleShark]

Because now nameof(Foo) and nameof(Foo, false) mean the same thing.

What's wrong with that? Its kinda the whole point of optional arguments. And if you dont like it being nameless, then fully qualify it as @hez2010 already did: nameof(Foo, fullName: true)

If you have "foo. bar".Split('.', StringSplitOptions.TrimEntries); then even without naming the second parameter it's immediately apparent what the parameter is doing.

Conversely, a hypothetical "foo. bar".Split('.', true); that does the same thing (optional boolean property indicating whether or not to trim the entries), is only obvious if you are familiar with the operation.

As for the topic on hand, fullnameof(Foo) is self documenting. nameof(Foo, true) could mean just about anything, and nameof(Foo, fullname: true) doesn't really help because not everyone will use named parameters. If you were unfamiliar with the overload and looking over someone else's code that doesn't use the named parameter, you would likely have some degree of confusion as to what it actually does.

If we were to do the second parameter approach, I would prefer an enum, like nameof(Foo, NameOfOptions.FullName), which is at least self documenting. But that's a whole new type being introduced when that information could be provided via the keyword.

[KieranDevvs]

If you were unfamiliar with the overload and looking over someone else's code that doesn't use the named parameter, you would likely have some degree of confusion as to what it actually does.

Nameless optional parameters are used everywhere in the language. .ConfigureAwait(false) for example, is used heavily.

doesn't really help because not everyone will use named parameters.

That argument could be used for literally any language feature and we would add nothing to the language. Just because someone might not follow good practices, is no reason to not add the language feature. Take lambdas for example, you don't have to name arguments anything meaningful yet lambdas are heavily used language feature.

MyMethod((guessWhatThisIs) => guessWhatThisIs % 2);

Or literally any time you pass null as an argument...

// What is null?
MyMethod(param1, null, param3);

Would an enum be better?... maybe its worth the extra type? but lets not pretend like nameless parameters is some how a blocker for the design of this.

[IanKemp]

Over seven years later and another basic language ask that is still not implemented, I'm sure the team will as usual justify it with "not enough interest" as they usually do for things that in reality they CBA to work on. Meanwhile Mapperly, and I imagine other projects, are coming up with their own implementations to cover for the lack of this simple yet important feature... I can guarantee that different projects will choose different ways of doing this and we'll end up with a fragmented ecosystem for no good reason.

If you don't want to implement this feature, how 'bout you hire some people who do? It's not as if you're working for a scrappy startup that can't afford to hire developers.

[mwpowellhtx]

Probably not along the lines of T``0 or whatever such similar representations tend to be. My two 💵 .

[jnm2]

That would be a departure from how nameof works. nameof gives the C# class or alias name, not the metadata name.

[jnm2]

If there was a chance of the C# compiler allowing typeof(X).FullName as a constant in attributes, that would feel the clearest and cleanest to me.

[whoisj]

typeof(T).FullName being constant would be amazing.

fullnameof(x) is interesting because for members it would be <namespace>.<type_name>.<member_name> but for parameters we'd need something new. <namespace>.<type_name>.<method_name>::<parameter> or something?

[jnm2]

Okay, let's do it! #8505

Please fill in with both use cases for constant typeof(...).FullName as proposed, as well as use cases for other variants like fullnameof which would behave differently, such as by allowing referencing things that aren't types, or by handling generics or nested type separators differently. If there are a lot of concrete use cases that typeof(...).FullName can't help with, that will be good to know.

[jnm2]

I'm proposing making typeof(...).FullName a constant, which will help with some of these use cases: #8505

It would be great to hear in that thread about real-world use cases that support doing this, as well as real-world use cases for fullnameof that aren't addressed by that proposal and don't have a good solution today.

Spoiler: rejected!

[CyrusNajmabadi]

Yes. This would only be for cases where the static information was enough to construct exactly the same string that would be computed at runtime. This would also require runtime to be ok with typeof(...).FullName never changing for that set of types.

[HaloFour]

I edited my comment to not use generic syntax typeof(T).FullName as obviously that would be a case where the compiler could not treat the expression as a constant. :)

[mwpowellhtx]

Well like I said, typeof(T) yields a Type instance. So anything down range of that, would need to be the constant. Probably gonna ruffle some feathers with that proposal.

[HaloFour]

Yes, and the compiler will completely skip those steps, based on the assumption that for any given typeref token that the namespace and type name will always be the same. That's not true of every property of Type, so this can only apply to a few select properties, such as FullName and Namespace.

[whoisj]

maybe instead of changing typeof(T) we add something like typename(T)?

[EtiTheSpirit]

This is a late reply giving more support to this proposition.

I'm getting tired of writing long and complicated messages for my development like $"{nameof(SomeProperty)} does nothing when {nameof(SomeType)}.{nameof(SomeType.SomeOtherProperty)} is set."

However this also raises a problem, which is to what extent the name is written out. Like in my use case, I don't want the namespace, only the class. An earlier comment suggested stringof() for this purpose which would work well for me.

[Flithor]

I've found this:
https://marcinjuraszek.com/2017/05/adding-matt-operator-to-roslyn-part-1.html
https://marcinjuraszek.com/2017/05/adding-matt-operator-to-roslyn-part-2.html
https://marcinjuraszek.com/2017/06/adding-matt-operator-to-roslyn-part-3.html

Perhaps stringof that could be done with a custom analyzer?

[KalleOlaviNiemitalo]

I imagine one could define fullnameof as a static overloaded method, access it via global using static, and use the "interceptors" feature in a source generator to replace each of its calls with a different call that returns the appropriate string. However AFAIK:

• The resulting strings would not be constant expressions like nameof makes.
• fullnameof(Object.ToString) and similar things, where you have a type name and the name of an instance method, would not work because the original method call being intercepted is not valid.
• There might be difficulty with using fullnameof with pointer types, which are not permitted as type arguments and thus would not be covered by a single static string fullnameof<T>(T arg) method. Maybe one could fix that by also generating additional methods; but I don't remember whether Roslyn requires them to be declared before the source generator runs.

If the syntax were full(nameof(expression)) instead, I think that would be easier to implement in a source generator, because the nameof part would allow instance members and squash all types to string so one static string full(string) method would suffice. The source generator would still see what's in the expression of nameof and would be able to generate the result value of the interceptor accordingly. The name full would have a higher risk with clashing with some other declaration, though.

[tb-mtg]

  public static string FullNameOf<T>(int parentLevel = 0) {
      if(parentLevel < 0)
		  parentLevel = 0;
      Type t = typeof(T);
      var fullName = t.FullName;
      var fullNameLastIndex = NthLastIndexOf(fullName, ".", parentLevel + 1 );
      return fullName.Substring(fullNameLastIndex + 1);
  }
	
  public static int NthLastIndexOf(string source, string value, int n){
    if (string.IsNullOrEmpty(source) || string.IsNullOrEmpty(value) || n <= 0)
        return -1;
    int index = source.Length;
    for (int i = 0; i < n; i++)    {
        index = source.LastIndexOf(value, index - 1, StringComparison.Ordinal);
        if (index == -1)
            return -1;
    }
    return index;
  }  

Console.WriteLine(FullNameOf<System.Data.IDbConnection>());   //            IDbConnection
Console.WriteLine(FullNameOf<System.Data.IDbConnection>(0));  //            IDbConnection
Console.WriteLine(FullNameOf<System.Data.IDbConnection>(1));  //       Data.IDbConnection
Console.WriteLine(FullNameOf<System.Data.IDbConnection>(2));  //System.Data.IDbConnection

Console.WriteLine(FullNameOf<IDbConnection>(-1)); //            IDbConnection
Console.WriteLine(FullNameOf<IDbConnection>(0));  //            IDbConnection
Console.WriteLine(FullNameOf<IDbConnection>());   //            IDbConnection
Console.WriteLine(FullNameOf<IDbConnection>(1));  //       Data.IDbConnection
Console.WriteLine(FullNameOf<IDbConnection>(2));  //System.Data.IDbConnection
Console.WriteLine(FullNameOf<IDbConnection>(3));  //System.Data.IDbConnection

[jnm2]

There are a lot of custom cases mentioned here, some with specialized handling such as wanting part of the namespace relative to another namespace. If infoof/memberof was implemented (#712), then this relatively simple syntax would open the door to folks generating their own specially-customized strings:

MyFormat(infoof(SomeMember))

Similar to how, today, you can already do:

MyFormat(typeof(SomeType))

This doesn't work in constant contexts, but it could be combined with a proposal to allow interceptors to intercept with a constant declaration instead of intercepting with a static method declaration. The compiler could then consider the intercepted expression to be constant. To make this more palatable and have better errors as a language feature, a sigil such as constexpr(...) could be used to require the contained expression to be an method call that is intercepted with a constant.

A downside would be that infoof would require method signatures to be specified if the name specifies a method group with more than one overload.

[Seramis]

I'm in full support of this feature, would love to have something like this built into the language.

I wanted to bring visibility to Mapperly library, specifically their version of "Full nameof".

It doesn't introduce any additional keywords, but just requires @ prefix in the nameof() argument.

The related logic seems to start here in their implementation.

So for full name, as their example shows, you would write:
nameof(@MyNamespace.Car.Make.Id).

[Seramis]

it will if you do nameof(FilterMethod)

Getting back to square one. This has been already exemplified here.

[HaloFour]

I don't think the "FilterMethod" string gets refactored in any IDE when the method is being renamed. Even with analyzers approach. Or am I wrong?

Also won't be if FilterMethod has overloads. But an analyzer can point out that the method name no longer exists and offer suggestions. Perhaps additional tooling could tie the analyzer into refactoring events.

[CyrusNajmabadi]

So we do need a full-nameof of some kind...

I have no idea what your proposal is. It's too vague to same "of some kind". A language proposal needs to be clear on what it is suggesting actually be added to the language.

To put in clearer terms: imagine we did 'fullnameof(...)' and you try to use it, and it just doesn't work for your use case at all. Then what? We added "of some kind", but you are still not satisfied.

If you want a "fullnameof" you really need to be explicit on exactly what it does, and how it fits into the rest of the language. So far, people are ALL over the map here. Some people want CLR type names. Some people want a general 'language quoter'. Some people want an expanded nameof. Some people want generics. Some don't. Some want aliases. Some don't. Some want non-named types (pointers/arrays/etc), some don't. etc. etc. etc.

We cannot build a feature out of this when there is so much vaguery and people are talking about wildly different concepts and capabilities.

[Seramis]

So we do need a full-nameof of some kind...

I have no idea what your proposal is. It's too vague to same "of some kind". A language proposal needs to be clear on what it is suggesting actually be added to the language.

I'm sharing scenarios and end-user syntax examples. Language proposals, as have been already referred here, live in Proposals/ path in repository. This discussion here is not that folder.

I really don't care how it is developed as long as the result of it can be used through reflection. For example I can call .Invoke on it eventually and it will actually invoke the method I pointed to through the full-nameof-thingy.

I played around [CallerArgumentExpression] approach and it is almost perfect approach, except that I have no way to get a 100% guaranteed correct type out of it because I have no knowledge of the file's context in terms of what using declarations exist there. There may be MyClass.MyMethod in multiple projects and it is impossible to derive which one was meant when nameof(@MyClass.MyMethod) was written.

I have never here tried to create a full proposal suitable to Proposals/ folder and I'm confused why would you expect my discussion comments be up to that level. They are not and probably never will be.

[CyrusNajmabadi]

I really don't care how it is developed as long as the result of it can be used through reflection

This is an example of requirement that is necessary to be explicit about.

And it shows the problem here. Multiple other people chiming in here over the past few days are looking for fullnameof to do something else entirely.

Your approach is fundamentally about the clr, and how it names and resolves things. That's very separate from the language and is not something we have ever exposed or considered something the language should know about.

We need to establish requirements like this as clearly there are vastly different views on what this feature would actually do.

And please(this applies to everyone), do not assume your views are apparent or shared by others. That's clearly not the case. I can count at least 4 disparate and non-complimentary requirements stated by people so far.

[CyrusNajmabadi]

For this to have any viable future, someone (either community or ldm) needs ot actually spec out what the proposed lang feature is and what semantics it actually has. I have just read through the entire thread (for the nth time) and it is strikign that this just isn't done anywhere. Effectively, people are asking for a fullnameof(...) syntax (or some isomorphic syntax) but not actually defining what that syntax does. It appears as if people think this is fully evident, but i cannot see any actual consensus on how this should behave. There are also may comparisons to things like typeof(X).FullName (which this new feature almost certainly would not behave like), or just stringify the expression input (which would be SUPER weird considering whitespace/comments) as well as lack of answers as to how this would behave for things like generics.

If this stands a chance of succeeding, this work needs to be done. It's not a syntax question. It's a question of semantics, and producing something reasonable, effective, and consistent.

[Rabadash8820]

someone (either community or ldm) needs ot actually spec out what the proposed lang feature is and what semantics it actually has

@CyrusNajmabadi I didn't realize this was a thing that community members had authority to do lol. Do you basically mean that somebody needs to create a document under the Proposals/ folder following the steps described in the Proposals Readme?

[Aniobodo]

What is the definition of "full name". Your example actually surprises me, as i would expect that fullnameof(B) would be A.B. It doesn't sound like teh 'full name', but rather just the expression components provided within fullnameof(...).

Additional questions: what are the set of legal expressions allowed with fullnameof. What do they all resolve to?

For example: this is legal for nameof: nameof(this.Length)

What does fullnameof do there?

If fullnameof(B) becomes A.B, that is too restrictive. That will mean that there is no difference between fullnameof(B) and fullnameof(A.B); so I do not think that this is what most people want.
The set of legal expressions allowed with fullnameof(...) can be the path characters only.

[CyrusNajmabadi]

If fullnameof(B) becomes A.B, that is too restrictive.

I genuinely don't know what semantics you want. If it's the "full" name, i'd expect "the full name". Stripping off part of the name makes it seem 'not full' to me.

The set of legal expressions allowed with fullnameof(...) can be the path characters only.

That becomes very odd and inconsistent. How does one specify the full name for a generic type, like you can do with nameof(...). It would be weird for fullnameof to not allow arguments that nameof allows.

[jnm2]

Plus, if you rename the type or adjust the usings at the top, various IDEs may qualify or unqualify the referenced name for you, in order to keep the code compiling, and this would break the idea that the full name is "whatever appears in code."

(Also what do you do about aliases?)

[jnm2]

@mattwar I would filter that list down to only valid C# syntax. nameof(List<>) produces List, where typeof(List<>).Name produces List`1. A fullnameof C# operator would not be importing and baking in the CLR's type formatting.

[mattwar]

@jnm2 I was only showing that there are lots of possible interpretations for what a full name could be. A proposal would have to define one that would satisfy all the kinds of possible types and members.

[jnm2]

For the sake of discussion, let's propose the following fullnameof operator. It produces only valid C# syntax; the string value it produces would be a valid input (syntactically) to nameof. It fully qualifies from the global namespace onward. It does not include extern alias qualifiers in the resulting string (though they may be used inside the expression).

It supports exactly the types and members that nameof supports, with three exceptions:

• It does not support bound generic types (List<int> or List<T>). It still supports unbound generic types (List<>).
• It does not support type parameters (there is no concept of "full name" for those).
• Aliases must not appear inside the fullnameof expression. This is to reduce confusion, since nameof(SomeAlias) produces "SomeAlias" and not the name of the aliased type.

Because of these rules, a full name identifies a type declaration or member declaration. It does not carry context relevant to the usage of the type, such as List<int>: "I'm using List<> with int!"

What scenarios are well served by this description? What scenarios aren't?

Examples

Expression	Value
fullnameof(System.Collections.Generic)	"System.Collections.Generic"
fullnameof(List<>)	"System.Collections.Generic.List<>"
fullnameof(Dictionary<,>)	"System.Collections.Generic.Dictionary<,>"
fullnameof(global::System.Func<>)	"System.Func<>"
fullnameof(someExtern::SomeType)	"SomeType"
fullnameof(ImmutableArray<>.Builder)	"System.Collections.Immutable.ImmutableArray<>.Builder"
fullnameof(ImmutableArray<>.Builder.Capacity)	"System.Collections.Immutable.ImmutableArray<>.Builder.Capacity"
fullnameof(List<int>)	❌ Not permitted
fullnameof(TSomeTypeParameterInScope)	❌ Not permitted
fullnameof((int A, int B))	❌ Not permitted
fullnameof(int[])	❌ Not permitted
fullnameof(int*)	❌ Not permitted
fullnameof(int?)	❌ Not permitted
fullnameof(string?)	❌ Not permitted

[CyrusNajmabadi]

The point of specifiers that they allow fulfilling many kind of different needs emerged in this thread (e.g. names with or without angle brackets, global specifier, namespace, assembly name, CLR-parseable format, etc.). A

I'm def averse to that. This now means the language has to design and support a set of format specifiers forever. And people will constantly want new capabilities and complexities. This is now defining a full serialization library for types/symbols, and codifying it into the language forever.

We already have something akin to that in Roslyn, and there are currently over 50 separate formatting options for it. And people still want more options. Furthermore, we def have bugs in the impl of some of these options (there are so many ways they can collide with each other), but changing any of the, is a breaking change for Roslyn.

Instead of this, i would MUCH rather go "you can augmetn intercepters to intercept something, and return some constant value to substitute in its place".

Then you could do something like:

[SomeAttr(MySpecialFunc(X.Y.Z, "MyFormatSpecifiers..."))] 

And interceptors would allow you to run whatever arbitrary code you wanted (using roslyn's existing formatting specifiers if you want to leverage those), and then replace it with a constant string you could embed there.

Then the language is out of this space entirely.

[HaloFour]

Instead of this, i would MUCH rather go "you can augmetn intercepters to intercept something, and return some constant value to substitute in its place".

Feels like that's wading into constexpr territory.

[koszeggy]

It is perfectly legal for the parser today.

Wait, that's cheating 😀

And it doesn't change the fact that parsing nameof (when it is not parsed as a method expression) already has a special handling in the parser (edit: nevermind, now I see ytou newr reply, too). But again, this could be avoided by (a?[b]):c, if c is meant to be a specifier (which can't be here, as this actually should raise CS8081: Expression does not have a name anyway, so maybe nameof(a?[b].Name:c) would be a better example). But aren't we distracted too far from the point again?

EDIT 2: I have the superpower of answering more than 5 minutes old answers slowly. No need to react to this.

[Jeremy-Price]

I can think of two useful scenarios for this that I didn't see mentioned:

One is source generators. It can be useful to generate fully qualified names to avoid disambiguation, and sometimes you want to generate names of types you have access to.

I would also find this useful in debug output, especially things like DebuggerDisplay or DebuggerTypeProxy.

I'm not sure I'm sold on not working for bound generics, though. I get the argument for it, but that behavior would be fairly unexpected for me, and it would be useful to have in my examples.

Feels like that's wading into constexpr territory.

Now that you mention it, I do have a feature request...

[CyrusNajmabadi]

One is source generators. It can be useful to generate fully qualified names to avoid disambiguation, and sometimes you want to generate names of types you have access to.

Note: in source generators, it is an explicit contract that calling ToDisplayString(FullyQualifiedFormat) on an ITypeSymbol will give you a legal c# string to reference that type in source.

[Flithor]

Plan B: stringof

I suggested this, you can talk about this here: #5520
Or Plan c: Proposal: syntax symbol string

The current design being considered is that any name that is valid in nameof will be allowed.
It will compile the name in code within the parentheses directly into a constant string.

However, although nameof allows new line, considering the intended function of this new operator, the parentheses in stringof may not allow line break chars.

Expression	Value
stringof(System.Collections.Generic.List<>)	"System.Collections.Generic.List<>"
stringof(global::System.Func<>)	"global::System.Func<>"
stringof(ImmutableArray<>.Builder.Capacity)	"ImmutableArray<>.Builder.Capacity" Suggest quick fix: To full name ↓
stringof(System.Collections.ImmutableArray<>.Builder.Capacity)	"System.Collections.ImmutableArray<>.Builder.Capacity"
stringof(List<int>)	"List<int>" suggest quick fix: To full CLR type name ↓
stringof(List<System.Int32>)	"List<System.Int32>"
stringof(TSomeTypeParameterInScope)	"TSomeTypeParameterInScope"
stringof((int A, int B))	"(int A, int B)"
stringof(int[])	"int[]"
stringof(int*)	"int*"
stringof(int?)	"int?"
stringof(string?)	"string?"
nameof (System.Collections. Generic.List<string>)	nameof returns: "List"
stringof (System.Collections. Generic.List<string>)	❌ Compile Error

[Rabadash8820]

It's worth calling out that your "Plan B" is not mutually exclusive with jnm2's fullnameof proposal and they serve slightly different needs. stringof does more than just fullnameof, while fullnameof allows less typing (e.g., fullnameof(FileInfo) returns "System.IO.FileInfo").

the parentheses in stringof may not allow line break chars

For that matter, maybe any leading/trailing whitespace inside the parentheses could be trimmed.

[Flithor]

@Rabadash8820 Regarding this, I thought: outputting the full readable name is mostly used for locating specific named token or code string in code, and is likely to be used with Ctrl+C followed by Ctrl+V in the editor search bar. If allows space characters, will arise a very awkward situation: cannot find this string.

Keep not allows space character might be okay, I think.

[Rabadash8820]

I think we're trying to achieve the same thing, namely avoiding spaces. I was saying that, to avoid whitespace in its output, stringof could trim its input. For example, stringof(<code>) and stringof( <code> ) would return the same thing.

[CyrusNajmabadi]

@Flithor We shoudl keep any discussion fo stringof to #5520. This discussion if for a fullnameof which looks to behave entirely differently from your suggested route.

[Flithor]

Maybe you should ask him: #5520 (comment) haha

[sator-imaging]

roughly spec-ed.

displaynameof (formerly fullnameof)

Concept: do nothing without request. (there is another operator clrnameof)

• displaynameof(Dictionary<>): unbounded generics
  • result: Dictionary
  • usecases:
    • build error message: $"The type '{displaynameof(Dictionary<>)' requires 2 type args, TKey and TValue}'"
    • construct reflection ready name: $"{displaynameof(Dictionary<>)}'2"
• displaynameof(Dictionary<K, V>): type parameters
  • result: Dictionary<K, V> (even though it should be TKey and TValue)
  • usecases:
    • build error message or generate documentation machinery: sb.AppendLine($"# class {displaynameof(Dictionary<TKey, TValue>)}")
• displaynameof(Dictionary<int, Int64>): constructed generics
  • result: Dictionary<int, Int64> (not long as developer requires Int64; IDE won't emit "it should be..." message)
  • usecases:
    • same to above
• Verbosity control:
  • if qualified name is required, just write it: displaynameof(global::System.Int32)
    • IDE won't emit "it should be..." message at all. just check reference correctness.
  • if partial name is required, just write it: displaynameof(Generic.Dictionary<bool, global::System.String>) (with using statements; may be invalid in current evironment)
  • if alias name is required, just write it. or write actual type name.
• Method Signatures:
  • displaynameof(Foo<>.GenericMethod<>): unbound generic
    • result: Foo.GenericMethod
  • displaynameof(Foo<>.GenericMethod<TValue>): unbound + type params
    • result: Foo.GenericMethod<TValue>
  • displaynameof(Foo<System.Int32>.GenericMethod<>): type params + unboud generic
    • result: Foo<System.Int32>.GenericMethod
  • ...and so on

Naming candidates:

• identifierof: seems like instanceof
• symbolof: a roslyn
• literalof: too widely scoped
• str_repr: string representation. smells C/C++, Rust

---

clrnameof

By contrast from nameof, it can be implemented with fresh syntax. (accepts formatting option like interpolated string hole).

• clrnameof(int,QV) or clrnameof(int:QV)
  • result (imagine most strict reflection name): qual_name_with_version[qual_with_ver, qual_with_ver]...
  • Q: emits qualified/full name of the type
  • V: appends assembly version

[CyrusNajmabadi]

Having the same symbol result in different "full name of" calls immediately makes the term "full" inconsistent/confusing.

If it's "full" it should not be cutting off data. If you actually want something "not necessarily full" then the language feature should be named appropriately.

This also applies to people that want clr names. If you want clr names, the feature should make that clear that that is what you are asking for and getting back.

[sator-imaging]

a little update: introducing displaynameof and clrnameof.

Honestly, if the complete list of /* lang=... /* and internal highlighter (C#-symbol-exists-only, if exists) are going to be exposed on MS Learn, it could be enough in 99% cases. I repeatedly tried lang=csharp, as lang=json,strict exists, but yesterday I realized it should be C#!

[sator-imaging]

One another spec.

Extended nameof Operator

Synopsis: nameof( <TYPE_OR_MEMBER> [, <FORMATS>] ) (or use : to mirrors interpolated string syntax)

Formatting options (case insensitive):

• F: Full name (for types; ignored if member)
• G: Full name with global:: prefix
• C: Containing types (for members; Foo.Member if no F/G, Namespace.Foo.Member with F)
• T: Type parameters/arguments: (nameof(List<>, T) emits List<T>, nameof(List<int>, T) emits List<int>)
• P: Parameters: (nameof(List<>.Add, P) emits Add(T))
• R: Return type (for method/property: int Length)
• M: Modifiers: IFoo<in T>, Method(in int, out int) if P present, ref T this if R present
• N: Nullable annotation: nameof(Foo.Method<>, TPRN) emits int? Method<T>(T?)
• S: Signature of the member (shorthand for TPRMN)
• X: eXtended parameters (emits param names): Method(ref int value, string optional)
• D: Default values of parameter: Method(ref int value, string optional = "Default Value")
• W: Emits type constraints: Foo<T> where T : ...
• V: Emits most verbose representation (GCSXDW)
• No Option: do the same with current behavior

Example:

• nameof(List<>.Add, "V") or just V
  • result: void global::System.Collections.Generic.List<T>.Add(T item)

[CyrusNajmabadi]

So far, in just the last few days there have been requests for:

1. a way to embed CLR names suitable by reflection. Note that we examined this when looking at making typeof(X).FullName constant, and decided this was likely never possible. That's because these names are not constant, and at runtime can be wholly different from the names computed at compile time.
2. a way to 'stringify' c# code. This is a massive can of worms on its own, as the example have shown that the argument to fullnameof call is effectively anything (including classes/namespaces/members/statements/expressions). It's unclear how on earth this would be parsed. It has also been said that there's no concept of what the syntax/semantics even means here. So effectively it is equivalent to just having a string just without quotes. Just consider for a moment how massive an undertaking it would be to try to support that sanely.
3. a way to get a C# view of the original code written, albeit with control on how whitespace is treated.
4. a way to have an arbitrary to-string'ing system for any symbol. Note that roslyn itself has over 50 ways to format symbols, so we know this is a massive sort of thing to then add to the language.
5. a way to get something similar to 'mapperly', although its approach is full of problems as well as already listed.
6. a way to get something that is a superset of 'nameof'.

There also appear to be entirely different views across teh board on how things like aliases, qualification, nesting, generics, tuples, arrays, pointers and so on, would be supported.

This is not something a realistic specification can be made from. THe use cases are MASSIVELY different, as are the expectations from one dev to the next.

The only viable options i could see are:

1. building a simple extension on top of nameof syntax/semantics that is very simple and clear to spec/impl. It would serve the use cases of some users, but def not all.
2. add a way to say "you can reference a symbol, and make a call to a method. that method can then be intercepted and replaced with a string-constant". then, all these higher up cases become calls to your new method that you intercept, and you can do WHATEVER you want in the body (including referencing roslyn's ToDisplayString and whatnot to access the wealth of roslyn symbol formatting capabilities).
3. just write things as a String, and use a StringSyntax attribute along with analyzers to actually check if your string literal is acceptable.

[whoisj]

well, as usually everybody want everything all of the time. No surprises there. 😂

[CyrusNajmabadi]

Not good enough:

You are describing ide features. Those are unrelated to the language.

Support can be added for StringSyntax, just as it could be for any of these other hypothetical proposals.

[Flithor]

If it's already been planned, then I have nothing to complain about it.

btw: so cool so cute alpaca of your avantar

[CyrusNajmabadi]

so cool so cute alpaca of your avantar

Thanks!

[Pyrdacor]

For me the main use case are fully specified types. For example in this case:

namespace X.Y.Z
{
    class Foo {}
    class Bar {}
    class Baz {}
}

namespace SomeOther
{    
    public static class Loader
    {
        public static Type LoadByName(string typeName)
        {
            // Current code
            return Assembly.GetExecutingAssembly().GetType($"{nameof(X)}.{nameof(X.Y)}.{nameof(X.Y.Z)}.{typeName}");
            // New code
            return Assembly.GetExecutingAssembly().GetType($"{fullnameof(X.Y.Z)}.{typeName}");
        }
    }
}

...
var type = Loader.LoadByName(nameof(X.Y.Z.Bar));

// With new syntax it could be even easier: var type = Assembly.GetExecutingAssembly().GetType(fullnameof(X.Y.Z.Bar));

Maybe just limit it to namespaces and types? Could be worth to use a different name like qualifiednameof(), scopenameof(), qnameof(), fqnameof() or pathnameof()?

[Thaina]

After reading many comment request similar feature as new keyword. I think this kind of request will eventually unavoidably became bloated

What we actually want is ability of compiler to specified const-able function/property and enforce that these kind of function can be used as const and attribute's parameter. And more type should be allowed to be attribute especially struct

typeof(int).FullName should be able to become constant. And we should allow get filename and filepath and projectpath of the current file as constant. Path.RelativeTo should also be const-able. And so we could also pass relative filepath into attribute or logging/tracing

This direction also compliment const expression

[colejohnson66]

const methods won't work. The compiler can't "look inside" methods in a different assembly; It could be compiling against a "ref" assembly. In a ref assembly, the body of every method is throw null; and nothing else.

[Thaina]

@colejohnson66 There could be a way to make a compiler annotate that some function was a constant-able at compile time, like AggressiveInlining attribute. And then allow it to be used at switch case / attribute / const

In the same manner as constant expression

[CyrusNajmabadi]

Constant values contain the actual value that is constant. This is describing a computable expression that has to be evaluatable by a compiler, yet produce a constant.

[Thaina]

@CyrusNajmabadi Yes, I think some property such as reflection like typeof(int).FullName could be and should be constant that evaluated by compiler at compile time