opDispatch compiles fine, but still fails to resolve?

Meta via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Fri Aug 8 19:52:10 PDT 2014


On Saturday, 9 August 2014 at 01:20:33 UTC, Vlad Levenfeld wrote:
> More opDispatch woes. This feature keeps biting me, yet I keep 
> trying to use it.
>
> This time I'm trying to access elements of a vector GLSL-style 
> (without swizzling... for now).
>
> Here's the relevant code:
>
> struct Vector (uint length, Element = double)
> {
> 		ref @property component (string c)()
> 		{
> 			enum mat = q{xyzw};
> 			enum col = q{rgba};
> 			enum tex = q{uv};
>
> 			static if (mat.canFind (c))
> 				return components[mat.countUntil (c)];
> 			else static if (col.canFind (c))
> 				return components[col.countUntil (c)];
> 			else static if (tex.canFind (c))
> 				return components[tex.countUntil (c)];
> 			else static assert (0);
> 		}
>
> 		ref @property opDispatch (string c)()
> 		if (c.length == 1)
> 		{
> 			auto v = component!c;
> 			pragma(msg, typeof(v)); // this outputs the expected result
> 			return v; // so everything is fine, right? wrong...
> 		}
>
> 	Element[length] components;
> }
>
> Calling vector.component!`x` or something works fine, but 
> calling vector.x fails with "Error: no property" etc.
>
> Now, I'm used to opDispatch silently failing when it can't 
> compile (very annoying btw), but in this case, I tested every 
> line with a pragma (msg, __traits(compiles...)) and everything 
> checks out. All expressions are verified CTFE-able. The 
> compiler apparently makes it all the way through the method 
> without a hitch, but then just fails symbol resolution anyway.
>
> Is this just a bug? Does anyone have any advice on what else to 
> try? I'm out of ideas (short of falling back on generating 
> property methods by string mixin).

Have you tried it without @property? It's probably that which is 
causing the "Error: no property" message. As far as I know, 
opDispatch *only* works for variable-like access (i.e., 
vector.x), so making it @property is unnecessary and probably, in 
this case, buggy.


More information about the Digitalmars-d-learn mailing list