On Fri, 25 Dec 2009 19:08:29 +0300, Eldar Insafutdinov <[email protected]> wrote:

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.

The issue you submited is an interesting one!
I responded to it in a bugzilla: http://d.puremagic.com/issues/show_bug.cgi?id=3646

Reply via email to