In 2.060head, is(FuncType PT == function) -> PT contains parameter identifiers. This change is introduced the commit: https://github.com/D-Programming-Language/dmd/commit/65acb8ca382f3cd2abea058552d78c147163a8fa It is useful for more metaprogramming, but this change may break existing codes that using std.traits.ParameterTypeTuple. See below sample code: void foo(int num, string name, int[int] map){} pragma(msg, ParameterTypeTuple!foo); // In 2.059, prints (int, string, int[int]) // In 2.060head, prints (int num, string name, int[int] map) void bar(ParameterTypeTuple!foo num) {} // Error: function test.bar parameter bar.num is already defined ==== If we change the implementation of ParameterTypeTuple template like follows: template ParameterTypeTuple(func...) if (func.length == 1 && isCallable!func) { static if (is(FunctionTypeOf!(func) P == function)) { //alias P ParameterTypeTuple; // Remove parameter names that original function has. template Id(T) { alias T Id; } alias staticMap!(Id, P) ParameterTypeTuple; } else static assert(0, "argument has no parameters"); } We can get 'a tuple that contains only parameter types', but it also removes parameter storage class... breaking existing codes REVISITED! void foo(ref int x){} pragma(msg, ParameterTypeTuple!foo); // will prints (int), not (ref int) ==== In current dmd, all of function parameters have names, written by user, or named by compiler internally (e.g. _param_0). Then we never get a tuple of 'parameter type with storage class but unnamed'. Then, if we want to parameter type tuple with storage classes, we cannot remove parameter name informations from the tuple. As far as I know, there is no workaround. So I think we should revert the commit 65acb8ca.
(In reply to comment #0) > In 2.060head, is(FuncType PT == function) -> PT contains parameter identifiers. > This change is introduced the commit: > > https://github.com/D-Programming-Language/dmd/commit/65acb8ca382f3cd2abea058552d78c147163a8fa > > It is useful for more metaprogramming, but this change may break existing codes > that using std.traits.ParameterTypeTuple. See below sample code: > > void foo(int num, string name, int[int] map){} > pragma(msg, ParameterTypeTuple!foo); > // In 2.059, prints (int, string, int[int]) > // In 2.060head, prints (int num, string name, int[int] map) > > void bar(ParameterTypeTuple!foo num) {} > // Error: function test.bar parameter bar.num is already defined > > ==== > > If we change the implementation of ParameterTypeTuple template like follows: > > template ParameterTypeTuple(func...) > if (func.length == 1 && isCallable!func) > { > static if (is(FunctionTypeOf!(func) P == function)) > { > //alias P ParameterTypeTuple; > > // Remove parameter names that original function has. > template Id(T) { alias T Id; } > alias staticMap!(Id, P) ParameterTypeTuple; > } > else > static assert(0, "argument has no parameters"); > } > > We can get 'a tuple that contains only parameter types', but it also removes > parameter storage class... breaking existing codes REVISITED! > > void foo(ref int x){} > pragma(msg, ParameterTypeTuple!foo); // will prints (int), not (ref int) > > > ==== > > In current dmd, all of function parameters have names, written by user, or > named by compiler internally (e.g. _param_0). Then we never get a tuple of > 'parameter type with storage class but unnamed'. > Then, if we want to parameter type tuple with storage classes, we cannot remove > parameter name informations from the tuple. > As far as I know, there is no workaround. So I think we should revert the > commit 65acb8ca. Can the new behaviour be expressed with a new ParameterTuple! trait or something? ParameterTypeTuple! makes sense as just types, but it would be nice to see a suite: ParameterTyple! with all details, ParameterNameTuple! just names, ParameterDefaultArgTuple!, you get the idea... ?
You're right, it does break existing code. I thought it was a worthwhile tradeoff to get the functionality Manu needed. But perhaps Manu's idea to do this tuple with a __traits is a better idea.
(In reply to comment #2) > You're right, it does break existing code. I thought it was a worthwhile > tradeoff to get the functionality Manu needed. > > But perhaps Manu's idea to do this tuple with a __traits is a better idea. See also the notes in github. https://github.com/D-Programming-Language/dmd/commit/65acb8ca382f3cd2abea058552d78c147163a8fa#commitcomment-1473583
I think this is a regression in 2.060head. https://github.com/D-Programming-Language/dmd/pull/1018 To support getting parameter names, there are two pulls. 1. Add new trait: __traits(parameterNames, func) https://github.com/D-Programming-Language/dmd/pull/951 2. An implementation of my idea: __traits(identifier, typeof(func)) https://github.com/D-Programming-Language/dmd/pull/1017
Done in an alternate way: https://github.com/D-Programming-Language/dmd/commit/08811d7abbb6cd6eeabef041122e1673b2044251