== Quote from Simen kjaeraas (simen.kja...@gmail.com)'s article
> %u <e...@ee.com> wrote:
> >> I'm not sure what you're getting at here. In what way that you don't
> >> like
> >> it is it enum-unlike?
> >
> > These two have distinctly different outputs ;P
> >
> > alias defineEnum!( "A", "B", "C" ) Bar;
> > writefln( typeof(Bar.A).stringof );
> >
> > enum Foo { A, B, C }
> > writefln( typeof(Foo.A).stringof );
> They do. There are ways around that - mostly by using string mixins
> on this form:
> template defineEnum( string name, T... ) {
> string defineEnum = "struct " ~ name ~ " {"
> // Stuff from other implementation goes here.
> "}"
> }
Of course! The encapsulation only needs to string mixin the struct signature.
> mixin( defineEnum!( "EnumName", "A","B","C" ) );
> This pattern is one of the reasons I have been lobbying for automatic
> mixin templates in D2 - it should look only like this:
> defineEnum!( "EnumName", "A","B","C" )
Looking more and more like typecons's defineEnum :)
though, supporting a non-continues range of values (which I don't need) will be
annoying in this setup, I think..
but, I think typecons uses the slow if version..
> > Won't the compiler even choke on the type size when feeding defineEnum a
> > hundred
> > elements or so?
> Types are limited to 64K of memory, I think. That should be enough for 16K
> elements in this case. If you're thinking of the horribly long names,
> I believe identifiers are hashed rather than being stored wholesale, once
> they move past 16K.
Good to know.
All this makes for a nice freachable D1 defineEnum, thanks!
