Fix issue 3309 parameter names trait #951
Conversation
Added a new traits call to get the parameter names of a function
|
All traits returning lists were changed to return expression tuples instead of arrays (e.g. I think this should do the same for consistency. |
| else if (ident == Id::parameterNames) | ||
| { | ||
| FuncDeclaration *f; | ||
| Dsymbol *s = getDsymbol((Object *)args->data[0]); |
There was a problem hiding this comment.
New code should not be using the data member of arrays. Use (*args)[0] instead, it's typed correctly.
|
It would be cool if this returned a tuple of symbols rather than strings - the strings can then be acquired from the symbols if needed. |
|
It would also be useful if default arguments could be acquired from this too. |
|
Interesting ideas. I went with string names only because that was the biggest piece missing from the introspection capabilities. And of course, there was already a bug report on it with a patch that I used as the starting point. Perhaps we should be considering a more generalized getParameters trait? We can already get argument types from std.traits. If you add parameterNames, the only thing missing would be default arguments. Is that enough of a reason for a more generalized trait? |
Those symbols only exist inside the function itself. How would it work in general? I don't see how it could. |
|
@JakobOvrum Good point. I'm not sure how best to handle that, perhaps as @jmaschme suggested we could have a getParameters trait that only worked within a function/method? |
|
@mrmonday, aye, I think that would be great, and I know of at least two people who have asked about exactly this kind of thing before on IRC (using the parameters to the current function as an expression tuple). Retrieving the symbol for the current function is also a frequently requested feature (simplifying interfaces for a lot of mixin-style code). Either way, I want to thank @jmaschme for taking on these important issues. Your effort is greatly appreciated! |
|
@mrmonday Only working within a function/method may not be sufficient. void someOtherFunction(int x, float y = 10.0); In this case, newFunc should be: newFunc(bool test, int x, float y = 10.0), ie, the copied parameters are NOT a tuple argument, they are 1st class parameters, retaining their names and default args. Note: Syntax in my example is for illustration only. I don't care at all how it's implemented, assuming the result is the same... @JakobOvrum, Yeah, I've often needed typeof(this_function), or something to that effect. |
|
Done as: 08811d7 |
Added a new traits call to get the parameter names of a function