• Eldar Insafutdinov <e.insafutdinov gmail.com> Dec 25 2009
• "Denis Koroskin" <2korden gmail.com> Dec 25 2009

Eldar Insafutdinov <e.insafutdinov gmail.com> writes:

Denis Koroskin Wrote:

 On Fri, 25 Dec 2009 17:19:42 +0300, Eldar Insafutdinov  
 <e.insafutdinov 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.

"Denis Koroskin" <2korden gmail.com> writes:

On Fri, 25 Dec 2009 19:08:29 +0300, Eldar Insafutdinov  
<e.insafutdinov gmail.com> wrote:

 Denis Koroskin Wrote:

 On Fri, 25 Dec 2009 17:19:42 +0300, Eldar Insafutdinov
 <e.insafutdinov 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.


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