Supplemental change for Issue 1983 - Delegates violate const

[9rnsr]

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

After fixing bug 1983, ReturnType, functionAttributes, and other function type trait templates will not work for overloaded function symbol. For @property functions, using typeof(propfunc) idiom would be better.

And, recently merged wrap and unwrap have wrong implementation against fixing bug 1983. I need fixing the incorrect code at the same time.

dlang/dmd#2130 requires this change.

[ghost]

So you're saying we will no longer be able to get ParameterTypeTuple in overloaded @Property setters/getters?

We need to be able to extract the return type and parameters from these functions:

@property void x(int newX) { _x = newX; }
@property int x() { return _x; }

Otherwise, how would you extract the parameter type of the setter in order to invoke it?

[9rnsr]

So you're saying we will no longer be able to get ParameterTypeTuple in overloaded @property setters/getters?

Yes. If you want to use ParameterTypeTuple for overloaded functions (either these are property function or not), you should pick up one of the overload by using __traits(getOverloads).

[ghost]

Ok, I guess it does make sense to go through overloads, like so:

import std.traits;

struct S
{
    @property void x(int) { }
    @property int x() { return 0; }

    void y() { }

    int z;
}

void main()
{
    foreach (member; __traits(allMembers, S))
    {
        foreach (overload; __traits(getOverloads, S, member))
        {
            pragma(msg, member ~ ": ReturnType: " ~
                        ReturnType!overload.stringof ~
                        " Params: " ~ ParameterTypeTuple!overload.stringof);
        }
    }
}

Writes:

x: ReturnType: void Params: (int)
x: ReturnType: int Params: ()
y: ReturnType: void Params: ()

I do have a feeling dlang/dmd#2130 will have a big impact on templated code. But it's better to do this now than later.

[ghost]

Btw Kenji, I hate to bug you about this, but one of the most problematic parts of implementing template code is having to work around this bug: Issue 7804.

If you find some free time, could you take a look at it sometime? It would be a great fix for 2.064.

[9rnsr]

7804 is rather an issue for grammar definition. Currently __traits is defined with TraitsExpression, but AliasDeclaration always takes a Type as the aliased thing. So, at first we need to define something like TraitsType in grammar. In basic I'll assign very low priority for syntactic language changes.

[9rnsr]

Ok. Auto-tester is now showing green.
@jmdavis , could you please review the change in std.datetime?

[ghost]

Kenji, what about this problem (maybe unrelated to the compiler fix but it's still relevant):

foo.d:

module foo;

struct S
{
    private void x(int) { }     // private overload
    public void x(float) { }   // public overload
}

test.d:

module test;
import foo;

void main()
{
    foreach (member; __traits(allMembers, S))
    {
        // Error: struct foo.S member x is not accessible
        foreach (overload; __traits(getOverloads, S, member))
        {
            static if (__traits(getProtection, overload) == "public")
            {
                // ... do something if accessible
            }
        }
    }
}

As you can see, by the time we get to test whether a symbol has some type of access we've already errored out. So how do we iterate through overloads to check if we even have access?

[9rnsr]

Currently I don't have sufficient opinion to the issue. But, in several cases the restriction should be relaxed. For example, aliasing non-static member function could avoid access check, because you cannot actually call the function by using aliased name. We need to list such acceptable cases.

[jmdavis]

@9rnsr The std.datetime changes look fine and definitely simpler. The result isn't quite the same, but I think that it's better at this point.

[9rnsr]

@jmdavis thanks for your quick reviewing.