Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compile time constant some reflection values #10972

Closed
benaadams opened this issue Apr 29, 2016 · 14 comments
Closed

Compile time constant some reflection values #10972

benaadams opened this issue Apr 29, 2016 · 14 comments

Comments

@benaadams
Copy link
Member

For example typeof(MyClass).Namespace could be an interned string?

@svick
Copy link
Contributor

svick commented Apr 29, 2016

Duplicate of dotnet/coreclr#2591 (though it doesn't explicitly mention Namespace or other string properties). Not sure whether this would be better implemented in Roslyn or CLR.

@gafter
Copy link
Member

gafter commented May 1, 2016

@benaadams Do you really mean "compile-time constant" in the language sense (i.e. could be using in a switch case expression), or do you mean you want more efficient generated code?

@gafter gafter added the Blocked label May 1, 2016
@benaadams
Copy link
Member Author

@gafter literally a compile time constant for the string values in the style of nameof(); where appropriate - not everything could go this way but some things could be resolved at compile time rather than runtime or jit time.

So typeof(MyClass).FullName could be resolved at compile time, but Type t; ... t.FullName probably couldn't.

More complex reflected items like bindings or assembly name I don't think would be able to be resolved at compile time as they may change as dlls were swapped or updated.

A corner case would be typeof(MyClass).FullName would fail quite badly at runtime if MyClass has changed namespace in or been removed form a dependent dll. However it would return a value if it was a compile time constant. However that behaviour is similar to nameof.

@gafter
Copy link
Member

gafter commented May 5, 2016

So this is actually a language change request, as whether or not a string is a constant is visible to the language.

@benaadams
Copy link
Member Author

benaadams commented May 5, 2016

Not sure; currently they are evaluated at runtime? Common use cases are in diagnostics and exceptions+logging which are slow areas anyway. Not hugely fussed about them working in switch would just be a nice extrapolation.

@benaadams
Copy link
Member Author

Or could be an extension to nameof to add namespace qualification to stay away from Type?

@paulomorgado
Copy link

@benaadams

namespaceof()

@benaadams
Copy link
Member Author

@paulomorgado that would work.

Rather than going

nameof(System) + '.' nameof(Collections) + '.' nameof(Generic) or typeof(Dictionary<string,string>).Namespace

You could go

namespaceof(Dictionary<string,string>)

or
namespaceof(Dictionary<string,string>) + '.' + nameof(Dictionary<string,string>)

Rather than typeof(Dictionary<string,string>).FullName

@paulomorgado
Copy link

@benaadams

fullnameof()

😄

@alrz
Copy link
Member

alrz commented May 6, 2016

Basically, most of properties coming out of typeof(and the type itself #8194) can be treated as compile-time constants (if the compiler cares enough). I think the "syntax" in the original post is the most flexible way of doing this, typeof(T).FullName. So practically typeof(T).Name and nameof(T) would be the same. (where T is not a generic type).

What I really want to see is the ability to do some computation on these values (read pure functions) and they still remain compile-time constants.

@alrz
Copy link
Member

alrz commented Apr 20, 2017

@benaadams May you move this to csharplang repo?

@mwpowellhtx
Copy link

I like it, and I am working on a use case where that might be interesting. i.e.

namespace Foo
{
    class Bar { }
}

// ...

const string barNameSpace = namespaceof(Bar); // "Foo" const string

@CyrusNajmabadi
Copy link
Member

Closing this out. We're doing all language design now at dotnet/csharplang. If you're still interested in this idea let us know and we can migrate this over to a discussion in that repo. Thanks!

@CyrusNajmabadi CyrusNajmabadi closed this as not planned Won't fix, can't repro, duplicate, stale Nov 8, 2022
@jnm2
Copy link
Contributor

jnm2 commented Oct 11, 2024

This is now proposed at dotnet/csharplang#8505.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants