"Nick Sabalausky" <a@a.a> wrote in message news:ikcepj$248p$1...@digitalmars.com... > > I think your main original problem was that there isn't really a way to > compose enums additively, only subtractive. >
That just gave me an idea: I think you should be able to get away with an ordinary union: enum STD { STD_ELEMENT_1 = 17, STD_ELEMENT_2 = 42, } enum AOnly { A_ACCESS_1 = 0x80, } enum BOnly { B_ACCESS_1 = 0x80, } union A { STD std; A a; } union B { STD std; B b; } void funcA(A a) { if(a.a == A_ACCESS_1) {} if(a.std == STD_ELEMENT_1) {} } void funcB(B b) { if(b.b == B_ACCESS_1) {} if(b.std == STD_ELEMENT_1) {} } In the general case, I'd be very hesitent to use a non-tagged union like this, because it wouldn't provide protection against accidentally having the same integer value for a member of STD and a member of A or B (which would obviously screw the whole thing up). But in your paricular case it doesn't seem that would likely be an issue. Of course, if you dodn't mind a heavier-weight OO-based solution, you could always use classes instead of enums and use static immutable class members as the possible values (and make the constructor private to prevent additional possible values), but personally I think that would be over-engineered compared to either the above or the mixin solution in my previous message.