Function meta information

[Eldar Insafutdinov]

Denis Koroskin Wrote:

> On Fri, 25 Dec 2009 17:19:42 +0300, Eldar Insafutdinov  
> <e.insafutdinov at gmail.com> wrote:
> 
> > Currently we have ParameterTypeTuple for extracting type list of  
> > function arguments. This is not enough. There should be a clean way to  
> > extract storage classes and default arguments if there are any. Any  
> > thoughts?
> 
> I guess you must parse string representation of the function to get  
> everythig you need as of now.
> I know someone already did this and posted his code on dsource.org, but I  
> can't tell where exactly I saw it out of my head.
> 
> If you decide to make your own implementation, here is a start:
> 
> struct Foo
> {
> }
> 
> void bar(ref Foo foo, int i = 42)
> {
> }
> 
> void Inspect(T)(T t)
> {
> 	pragma(msg, T.stringof);
> }
> 
> void main()
> {
> 	Inspect(&bar);
> }
> 
> Output:
> void function(ref Foo foo, int i = 42)
> 
> Note that function properties are *extremely* bugged ATM - compiler  
> mistakenly thinks that "bar" and typeof(bar)", or "bar.stringof" and  
> "bar().stringof" are interchangeable (omissible parens hell). For example:
> 
> template ToString(alias func)
> {
> 	pragma(msg, typeof(func).stringof);
> 	enum ToString = typeof(func).stringof;
> }
> 
> void main()
> {
> 	enum s = ToString!(bar);
> }
> 
> results in the following output:
> 
> test.d(11): Error: expected 2 function arguments, not 0
> (void(ref Foo foo, int i = 42))() // TADAM!
> test.d(12): Error: expected 2 function arguments, not 0
> test.d(17): Error: template instance test.ToString!(bar) error  
> instantiating
> 
> This one will hopefully resolved once @property feature gets implemented  
> and omissible parens will go away.

Yes I know about parsing stringof. That is really non-trivial as it might look like, besides dmd doesn't release memory in ctfe mode, I really want to avoid it. The point I am trying to make is: if we have ParameterTypeTuple in the standard library, we should have a standard mechanism for extracting the rest of the information.

Also I have posted a bug today, #3646, which shows how fragile this kind of information is.