On Thu, Mar 15, 2012 at 11:50:47PM +0400, Dmitry Olshansky wrote: [...] > >This is one major area that I forgot to mention, and that is, making > >AA literals work at compile-time. Currently things like this don't > >work: > > > > enum myAA = ["abc":123, "def":456]; > > > >I'd like to make that work. That would require compile-time > >construction of the AA and storing it in some form that the compiler > >can put into the object file. > > What's wrong with AA structure itself, it's link-pointer based? At > any rate, I stored complex structs as immutable, though links were > index-based.
Yes, that's what I had in mind. In fact, I've starting testing a statically-declared AA (written by hand for now), that uses the same structures as heap-allocated AA's. The basic stuff (declaring Slots statically, linking them together, etc.) works, and in principle can be generated by mixins at compile-time to give us "true" compile-time AA literals (as in, the AA struct is computed at compile-time and stored in the static data segment in the object file). This can be used for implementing immutable AA's at compile-time (and maybe also "fast" initialization of AA literals which can be .dup'd at runtime into mutable AA's when needed). However, I've run into a major roadblock: the hash computation of the keys itself. Unfortunately, currently there's no (reliable) way to compute the hash of built-in types unless you use its TypeInfo, and TypeInfo's are currently not CTFE-accessible, so hash values cannot be computed at compile-time. :-( T -- He who laughs last thinks slowest.