On 11 May 2012 08:26, SebastianA <[email protected]> wrote: > On Friday, 11 May 2012 at 07:18:30 UTC, Jonathan M Davis wrote: >> >> On Friday, May 11, 2012 09:10:37 SebastianA wrote: >>> >>> Okay, thanks for the info. The weird thing is, if I change the >>> line to: >>> >>> t.vPosition = Vec(2, 2); >>> >>> it compiles and works, even if the property is ref. As far as I >>> know, this does nothing towards correcting the rvalue issue. >>> Should this also cause an error? >> >> >> struct literals work. They at least used to be lvalues for some bizarre >> reason. I'm not sure if they are now, because it went back and forth prior >> to >> the last release. They're either still lvalues or the first part of making >> rvalues work with ref has been implemented (but only with struct >> literals). >> I'm not sure which. >> >> - Jonathan M Davis > > > I did this very naive test: > > "Vec(2, 2) = Vec(3, 4);" > > which gave me the error > > "test.d(30): Error: Vec(2,2) is not an lvalue" > > so apparently it's not an lvalue, at least not in that sense. > > Anyway, thanks for the info. We can probably get around the problem by using > non-ref parameters for now. It is very weird that GDC accepts the code > though, and it even works when running a debug build. >
The copy of GDC you have is probably on build 2.057 - two releases behind the current language implementation. I have been testing your example on my development tree, and can't reproduce the issue of it returning (0,0) after the ternary assignment - though it does compile fine. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
