On Friday, 8 November 2013 at 04:28:31 UTC, Ross Hays wrote:
>
> class Vector(int N, T) if (N <= 3) {
>     T[N] data;
>
>     this()
>     {
>     	data[] = 0;
>     }
>
>     @property ref T opDispatch(string fieldName, Args ...)(Args args)
>         if (Args.length < 2 && fieldName.length == 1 && toOffset(fieldName) < N)
>     {
> 	    int offset = fieldName[0 .. 1] - 'x';
> 	    if (args.length != 0)
> 	    	return data[offset];
> 	    else
> 	    	return data[offset] = args[0];
>     }
> }
>
> Same error.

Sorry, I forgot to mention in that post that you have "toOffset" in your template constraint, which means it will also never match. You'll have to define it or replace it with `fieldName[0] - 'x';`

Also, you might not want to do `fieldName[0 .. 1]` because that's a slice (which is just another array of length 1). It won't do what you're expecting.

> Sorry, I forgot to mention in that post that you have "toOffset" in your template constraint, which means it will also never match. You'll have to define it or replace it with `fieldName[0] - 'x';`
>
> Also, you might not want to do `fieldName[0 .. 1]` because that's a slice (which is just another array of length 1). It won't do what you're expecting.

And more stupid mistakes on my part. Thank you, still not 100% there with D but working on it. (though some of those mistakes were dumb even outside of D lol).

class Vector(int N, T) if (N <= 3) {
    T[N] data;

    @property ref T opDispatch(string fieldName, Args ...)(Args args)
        if (Args.length < 2 && fieldName.length == 1 && fieldName[0] - 'x' < N)
    {
	    int offset = fieldName[0] - 'x';
	    static if (args.length != 0)
	    	return data[offset];
	    else
	    	return data[offset] = args[0];
    }
}

void main()
{
	Vector!(2, float) t = new Vector!(2,float)();
	writeln(t.x);
}

Another revision, still the same problems and I am pretty sure I am not forgetting anything this time... I am sure that is wrong too

On Friday, 8 November 2013 at 04:38:23 UTC, Ross Hays wrote:
> Thank you

No problem. I'm glad we're making progress on it. And don't feel bad about mistakes while learning. They happen. Embrace them because they happen to all of us at first especially when we're juggling learning new syntaxes and tricks and such.

>
> class Vector(int N, T) if (N <= 3) {
>     T[N] data;
>
>     @property ref T opDispatch(string fieldName, Args ...)(Args args)
>         if (Args.length < 2 && fieldName.length == 1 && fieldName[0] - 'x' < N)
>     {
> 	    int offset = fieldName[0] - 'x';
> 	    static if (args.length != 0)
> 	    	return data[offset];
> 	    else
> 	    	return data[offset] = args[0];
>     }
> }

Okay, your static if's condition is swapped (args.length should be 0 if you're just returning data[offset]).

Also, when you correct that, you'll run into an issue where it reveals that `data[offset] = args[0]` is not an lvalue (which is required for ref). Either change the return type to "auto" and remove the return for that branch... or, alternatively, you can split the statement into two:

else {
  data[offset] = args[0];
  return data[offset];
}

and `data[offset]` will be an lvalue.

Boom, that last few were the issues. I elected to just move the return for the setter onto a separate line, mostly because the idea of auto returning different types seem foreign to me... I have used auto plenty in C++11, but never like that and it just throws me off. But fixing those other mistakes we get:

class Vector(int N, T) if (N <= 3) {
    T[N] data;

    this()
    {
    	data[] = 0;
    }

    @property ref T opDispatch(string fieldName, Args ...)(Args args)
        if (Args.length < 2 && fieldName.length == 1 && fieldName[0] - 'x' < N)
    {
	    int offset = fieldName[0] - 'x';
	    static if (args.length == 0)
	    {
	    	return data[offset];
        }
	    else
	    {
	    	data[offset] = args[0];
	    	return data[offset];
        }
    }
}

void main()
{
	Vector!(2, float) t = new Vector!(2,float)();
	writeln(t.x);
	t.x = 4;
	writeln(t.x);
}

That works as intended, now if only it were useful.

And let me say that I really do like that this works in D. I can't imagine doing anything like this in C++ (which is what I used primarily in the past).

The only reason I joke about it being useless is it really only supports vectors of length 2 or 3 (technically 1 as well but that is not really a vector) and at that point I am tempted to say it is more efficient to just make a Vector2!float class or something of the sorts.

Okay here is something I was hoping for some general clarification on related to this and maybe you can help me sort some things out.

The opDispatch method has a template parameter of string fieldName. In C++, templates are actually compiled so each different use of a template class is compiled into its own thing. With D, if this is the case I imagine I would not be able to access the template parameter of string? If I can then why does it need to be a template parameter at all and not a normal parameter.

On Fri, Nov 8, 2013 at 5:55 AM, Ross Hays <throwaway@email.net> wrote:

> And let me say that I really do like that this works in D. I can't imagine doing anything like this in C++ (which is what I used primarily in the past).
>
> The only reason I joke about it being useless is it really only supports vectors of length 2 or 3 (technically 1 as well but that is not really a vector) and at that point I am tempted to say it is more efficient to just make a Vector2!float class or something of the sorts.
>

Then the next step is to allow swizzling (sp?) :-)

auto myVec = yourVec.yzx; // myVec.x = yourVec.y, myVec.y = yourVec.z, myVec.z = yourVec.x;

auto myVec2 = yourVec.xxx; // and so on

On Friday, 8 November 2013 at 05:10:57 UTC, Ross Hays wrote:
> Okay here is something I was hoping for some general clarification on related to this and maybe you can help me sort some things out.
>
> The opDispatch method has a template parameter of string fieldName. In C++, templates are actually compiled so each different use of a template class is compiled into its own thing. With D, if this is the case I imagine I would not be able to access the template parameter of string? If I can then why does it need to be a template parameter at all and not a normal parameter.

Yes, D is the same as C++ in that each unique template instantiation is compiled differently. Almost like copy & paste where you replace the template parameters with what was passed in.

What do you mean by "not be able to access the template parameter of string"? If you just mean whether you can use it or not, well, you can. It's available to you both at compile time and at run time if it's a template parameter like that. In the case of opDispatch, the compiler essentially rewrites all unknown calls (if `x.foo()` doesn't exist, then change it to `x.opDispatch!"foo"()`). One of the reasons why passing it in as a template parameter is better than a regular parameter is that opDispatch!s can specialize at compile time so that it doesn't result in any runtime performance hit.

You can look at it like this: with a compile-time opDispatch means that `opDispatch!"x"; opDispatch!"y";` and so on is (essentially) binary equivalent to you having actually hand-written those functions (that is just a hand-written `x` or `y`  property). So, there's no runtime overhead of conditionals, no allocating strings, no actual passing of parameters, or, potentially, even the creation of that offset variable (so, it doesn't even do the subtraction at runtime because it can figure it out at compile time and just fill it in as if it were a literal).

One tiny place of improvement for your code, however, is if you changed it to `static immutable offset = ...;` because that helps the compiler know to do that operation at compile time. That said, a Sufficiently Smart Compiler (tm) would be able to do it regardless of the extra hint, but AFAIK DMD typically doesn't do all of the optimizations it could.

Chris Cain:

> One tiny place of improvement for your code, however, is if you changed it to `static immutable offset = ...;` because that helps the compiler know to do that operation at compile time.

The idiomatic way to do that is to use "enum offset = ...;".

Bye,
bearophile

On 11/07/2013 10:05 PM, Philippe Sigaud wrote:
> On Fri, Nov 8, 2013 at 5:55 AM, Ross Hays <throwaway@email.net> wrote:
>
>> And let me say that I really do like that this works in D. I can't imagine
>> doing anything like this in C++ (which is what I used primarily in the
>> past).
>>
>> The only reason I joke about it being useless is it really only supports
>> vectors of length 2 or 3 (technically 1 as well but that is not really a
>> vector) and at that point I am tempted to say it is more efficient to just
>> make a Vector2!float class or something of the sorts.
>>
>
> Then the next step is to allow swizzling (sp?) :-)
>
> auto myVec = yourVec.yzx; // myVec.x = yourVec.y, myVec.y = yourVec.z,
> myVec.z = yourVec.x;
>
> auto myVec2 = yourVec.xxx; // and so on
>

Manu Evans had reported either during his talk at DConf 2013 or during private conversations at the same conference that the technique has been used at Remedy Games.

Ali