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.
