[Issue 8261] New: std.traits.ParameterTypeTuple may break existing codes

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=8261

           Summary: std.traits.ParameterTypeTuple may break existing codes
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody at puremagic.com
        ReportedBy: k.hara.pg at gmail.com


--- Comment #0 from Kenji Hara <k.hara.pg at gmail.com> 2012-06-18 08:26:10 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------