nameof(null) and friends

[RenderMichael]

The capabilities of nameof have recently been enhanced to allow specifying parameters from member attributes. I propose the power of nameof gets enhanced further, to allow various literals.

• nameof(null)
• nameof(false) <- in contrast with bool.FalseString, which is False rather than false
• nameof(true) <- ditto bool.TrueString
• nameof(123) <- compile-time 123.ToString(), without overflow issues

The above examples are some that I've had need for. There are others which can be made to "just work" as a way of rounding things out, like nameof(string) etc. but I will not be advocating for those.

[RenderMichael]

Arguments in support for this are the same as for nameof broadly: by strongly-typing string literals, it avoids potential typos as well as adding whatever intellisense support exists for these keywords. It avoids the need for const NullString => "null" proliferation within projects that care about such a string literal, such as serializers and loggers.

[jnm2]

What I know as the advantages to using nameof are the following:

• Safer renames
• Visibility in find-all-references when you want to know about all usages

These don't apply to nameof(false).

Taking advantages you listed:

• Strong typing. I would disagree that this is strong typing, because when you want strings like false it will also offer strings like int and 123.
• Avoiding potential typos. I would disagree that this has advantages over spell checkers, code review, unit tests, and declaring constants.
• Avoiding the need to repeatedly declare constants in various projects, such as serializers and loggers. I would disagree that serializers and loggers should use nameof even if this feature did exist. Unless they're serializing actual C#, they are not really referring to the C# language keyword even if it happens to match with the JSON language keyword or the logging lingo.

I would suggest instead a thing that comes with all these benefits and more: string-based enums (#2849). With string-based enums, you can actually obtain strong typing by restricting what sets of things go together, rather than allowing int and 123 when you want true/false/null.

[RenderMichael]

Those are all fair points. Additionally, the term nameof doesn't really work for literals. "Name" in that sense meant to refer to Type.Name or MemberInfo.Name, whereas that doesn't apply to nameof(false). Conceptually people could come to the conclusion that it would return "bool".

Thanks for the consideration.