[Issue 8261] std.traits.ParameterTypeTuple may break existing codes
http://d.puremagic.com/issues/show_bug.cgi?id=8261 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Walter Bright 2012-07-01 00:44:00 PDT --- Done in an alternate way: https://github.com/D-Programming-Language/dmd/commit/08811d7abbb6cd6eeabef041122e1673b2044251 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8261] std.traits.ParameterTypeTuple may break existing codes
http://d.puremagic.com/issues/show_bug.cgi?id=8261 Kenji Hara changed: What|Removed |Added Keywords||pull, rejects-valid Severity|normal |regression --- Comment #4 from Kenji Hara 2012-06-19 07:11:27 PDT --- 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 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8261] std.traits.ParameterTypeTuple may break existing codes
http://d.puremagic.com/issues/show_bug.cgi?id=8261 --- Comment #3 from Kenji Hara 2012-06-18 17:33:11 PDT --- (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 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8261] std.traits.ParameterTypeTuple may break existing codes
http://d.puremagic.com/issues/show_bug.cgi?id=8261 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright 2012-06-18 17:16:17 PDT --- 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8261] std.traits.ParameterTypeTuple may break existing codes
http://d.puremagic.com/issues/show_bug.cgi?id=8261
Manu changed:
What|Removed |Added
CC||turkey...@gmail.com
--- Comment #1 from Manu 2012-06-18 13:31:45 PDT ---
(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... ?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
