On 7/9/14, 4:18 PM, Bob wrote:
> Hi, I hit problem with templates/opDispatch.
>
> http://pastebin.com/rc09yWNt
>
> % uname -a
> Linux machine 3.11.0-20-generic #35-Ubuntu SMP Fri May 2 21:32:49 UTC
> 2014 x86_64 x86_64 x86_64 GNU/Linux

What does this event mean? Where does xyz come from? The code below also compiles in 2.065.0 on osx, but comment out opDispach() and it fails with the same error message as above.

Seems to be a bug that got fixed.

void main() {
    auto e = Vec4(5, 3, 3, 1);

    // This worked with dmd_2.065.0-0_amd64
    // but does not work with dmd_2.066.0~b2-0_amd64
    auto x = e.xyz; // Error: no property 'xyz' for type 'Vec!4'
}

alias Vec4 = Vec!4;

struct Vec(int dim) {

    union {
        struct {
            float h;
            float i;
            float j;
            static if (4 <= dim) float w;
        }
    }

    this(float h, float i, float j, float w) {}

    auto opDispatch(string components)() const {
        Vec!(1) result = void;
        return result;
    }
}

On 7/9/14, 5:58 PM, Andrew Edwards wrote:
> On 7/9/14, 4:18 PM, Bob wrote:
>> Hi, I hit problem with templates/opDispatch.
>>
>> http://pastebin.com/rc09yWNt
>>
>> % uname -a
>> Linux machine 3.11.0-20-generic #35-Ubuntu SMP Fri May 2 21:32:49 UTC
>> 2014 x86_64 x86_64 x86_64 GNU/Linux
>
> What does this event mean? Where does xyz come from? The code below also
> compiles in 2.065.0 on osx, but comment out opDispach() and it fails
> with the same error message as above.
>
> Seems to be a bug that got fixed.
>

This works in 2.065.0 also:

void main() {
    auto e = Vec4(5);

    // This worked with dmd_2.065.0-0_amd64
    // but does not work with dmd_2.066.0~b2-0_amd64
    auto x = e.xyz; // Error: no property 'xyz' for type 'Vec!4'
}

alias Vec4 = Vec!4;

struct Vec(int dim) {

    this(float h) {}

    auto opDispatch(string components)() {
        Vec!(1) result = void;
        return result;
    }
}

remove the "string components" parameter form opDispatch to reveal the same error.

On Wednesday, 9 July 2014 at 12:11:13 UTC, Andrew Edwards wrote:
> remove the "string components" parameter form opDispatch to reveal the same error.

Hm, could you elaborate a bit further on this? As per the spec, opDispatch requires a string parameter (http://dlang.org/operatoroverloading.html#Dispatch). Removing it means that the compiler no longer considers the template to match the opDispatch signature, and thus of course .xyz fails.

David

On Wednesday, 9 July 2014 at 12:21:20 UTC, David Nadlinger wrote:
> On Wednesday, 9 July 2014 at 12:11:13 UTC, Andrew Edwards wrote:
>> remove the "string components" parameter form opDispatch to reveal the same error.
>
> Hm, could you elaborate a bit further on this? As per the spec, opDispatch requires a string parameter (http://dlang.org/operatoroverloading.html#Dispatch). Removing it means that the compiler no longer considers the template to match the opDispatch signature, and thus of course .xyz fails.
>
> David

My concern is that this shouldn't compile in the first place. What is xyz?, Is it a free function? Is it a member variable or function?  In my mind it is neither of the two so why does it compile? Removing the string changes the signature of opDispatch but as shown in my prior example, there are orther ways to cause this error.

On Wed, Jul 09, 2014 at 14:56:59 +0000, Andrew Edwards via Digitalmars-d-announce wrote:
> My concern is that this shouldn't compile in the first place. What is xyz?, Is it a free function? Is it a member variable or function?  In my mind it is neither of the two so why does it compile? Removing the string changes the signature of opDispatch but as shown in my prior example, there are orther ways to cause this error.

It's swizzling. gl3n[1] implements it as well.

--Ben

[1]https://github.com/Dav1dde/gl3n/blob/master/gl3n/linalg.d#L375

On Wednesday, 9 July 2014 at 14:57:01 UTC, Andrew Edwards wrote:
> My concern is that this shouldn't compile in the first place. What is xyz?, Is it a free function? Is it a member variable or function?  In my mind it is neither of the two so why does it compile?

Oh, but that's precisely the point of opDispatch. ;) It offers a mechanism to respond to any members that are not found. See the spec for an example: http://dlang.org/operatoroverloading.html#Dispatch

David

On Wednesday, 9 July 2014 at 15:39:50 UTC, David Nadlinger wrote:
> On Wednesday, 9 July 2014 at 14:57:01 UTC, Andrew Edwards wrote:
>> My concern is that this shouldn't compile in the first place. What is xyz?, Is it a free function? Is it a member variable or function?  In my mind it is neither of the two so why does it compile?
>
> Oh, but that's precisely the point of opDispatch. ;) It offers a mechanism to respond to any members that are not found. See the spec for an example: http://dlang.org/operatoroverloading.html#Dispatch
>
> David

Exactly. opDispatch catches calls to missing methods and acts based on method name which it gets as a string at compile time. In this case, the idea is this:

        auto v1 = Vec!4(4, 5, 6, 7);
        auto v2 = v1.xyz;   // => Vec!3(4, 5, 6);
        auto v3 = v1.wx;    // => Vec!2(7, 4);
        auto v4 = v1.wxx1;  // => Vec!4(7, 4, 4, 1);

On 7/10/14, 2:35 AM, Bob wrote:
> On Wednesday, 9 July 2014 at 15:39:50 UTC, David Nadlinger wrote:
>> On Wednesday, 9 July 2014 at 14:57:01 UTC, Andrew Edwards wrote:
>>> My concern is that this shouldn't compile in the first place. What is
>>> xyz?, Is it a free function? Is it a member variable or function?  In
>>> my mind it is neither of the two so why does it compile?
>>
>> Oh, but that's precisely the point of opDispatch. ;) It offers a
>> mechanism to respond to any members that are not found. See the spec
>> for an example: http://dlang.org/operatoroverloading.html#Dispatch
>>
>> David
>
> Exactly. opDispatch catches calls to missing methods and acts based on
> method name which it gets as a string at compile time. In this case, the
> idea is this:
>
>          auto v1 = Vec!4(4, 5, 6, 7);
>          auto v2 = v1.xyz;   // => Vec!3(4, 5, 6);
>          auto v3 = v1.wx;    // => Vec!2(7, 4);
>          auto v4 = v1.wxx1;  // => Vec!4(7, 4, 4, 1);

Okay, got it. Thanks to both you and David for the clarification. A bug report was filed:

https://issues.dlang.org/show_bug.cgi?id=13087