Denis Koroskin Wrote:

> On Fri, 25 Dec 2009 17:19:42 +0300, Eldar Insafutdinov  
> <[email protected]> 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.

Reply via email to