On 08/01/2013 03:29 AM, JS wrote: > On Thursday, 1 August 2013 at 05:22:46 UTC, Ali Çehreli wrote: >> On 07/31/2013 06:10 PM, JS wrote: >>> http://dpaste.dzfl.pl/dbb40dbc >>> >>> The code was pared down from a lot of string mixin code generation. I >>> nest the structs because I want a nested enums. I don't want have to >>> have eState and eStateType but eState and eState.Type. >>> >>> Having the ability to nest enums would solve my problem. >>> >>> Regardless, I can almost achieve the effect with nested structs but not >>> quite. >>> >>> In the code, I cannot assign to the struct for some reason even with >>> alias this on iB, which should make State act like the int Value. >>> >>> i.e., >>> >>> b.State.Value = Enums.State.A; >>> >>> works but >>> >>> b.State = Enums.State.A; >>> >>> doesn't >>> >>> It maybe some stupid error on my part but I can't keep my eyes open >>> enough to figure it out... >>> >>> >>> >> >> For that assignment to work, the left-hand side must be assignable. >> However, the property function State() returns Enums.eState by-value. >> >> The following has the same issue: >> >> struct S >> { >> int i_; >> >> @property int i() { >> return i_; >> } >> >> alias i this; >> } >> >> void main() >> { >> auto s = S(); >> s = 42; >> assert(s.i == 42); >> } >> >> Error: cannot implicitly convert expression (42) of type int to S >> >> To compile, i() must return an lvalue: >> >> @property ref int i() {
Although, what I said seems more like a workaround because you already had a setter @property. You shouldn't need to make the getter return a reference as well... I guess...
I think what is at play here is the current implementation limitation of "a single 'alias this' per type." I think 'alias this' happens to pick the getter perhaps because the getter function is defined first in the class. I don't know...
Ali
