"Brad Roberts" <bra...@bellevue.puremagic.com> wrote in message
news:alpine.deb.2.00.0903121755240.4...@bellevue.puremagic.com...
That said, I don't think this really helps the desired usecase much. It's
useful, don't get me wrong, but still requires code to build up the
bi-directional translations. Or am I missing something? Seems to be
happening to me a lot lately, so I'm very prepared to be wrong here too.
:)
You're not wrong :)
The problem is that the foreach variable is not evaluatable to a
compile-time string. I don't know why, but I'll figure it out tonight.
I've also managed to convert an enum to an AssocArrayLiteralExp* (with the
name/string as the key and the value/int as the value) but it seems that it
cannot be foreached at compile time, even if it's a literal expression. But
hell, I've spent about 1 hour browsing through dmd's code, so I'm pretty
sure it's possible with a little more research.
I want to get either one to work at compile-time. In the case of TupleExp,
one could then use a string mixin to convert the string to a value.
L.
* I don't have the AA patch handy (I'm at work) but it's a good exercise:
start with my original tupleof patch but create an AssocArrayLiteralExp
instead of the TupleExp. You'll need two Expressions arrays, one for keys
and one for values. EnumMember::ident is the name, EnumMember::value is the
value expression. Pretty straightforward.
