Emulating enums

[JS]

On Thursday, 1 August 2013 at 16:36:34 UTC, Ali Çehreli wrote:
> 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

So, a ref'ed getter is the same as a setter?

Also, it would see, I'm guessing, that using alias this on a 
property and having to ref will bypass the setter?