On Thu, Feb 27, 2020 at 10:11:07AM -0500, Steven Schveighoffer via Digitalmars-d-announce wrote: [...] > Large hidden invisible types are not the problem (look at normal > dynamic arrays, the large hidden type built into the runtime is a huge > success I think). The problem is that the compiler gives special > features to such types. > > In the case of AA, the ONLY missing piece that cannot be implemented > by user types is this: > > int[string][string] aalist; > > aalist["hello"]["world"] = 5; > > In essence, the compiler knows how to make this work. The operators > available do not allow this expression to be captured properly by user > code (i.e. we don't have opIndexIndexAssign or > opIndexIndexIndexAssign, nor does that scale).
It's not that hard: https://issues.dlang.org/show_bug.cgi?id=7753 Somebody just has to do it, that's all. > I believe the last person to try and implement a full template type > that could replace AAs is H. S. Teoh. He would have a better > explanation (and possibly contradict me, I don't know). Actually, I may have been the *first* one to try to do this, but I don't think I was the last. Over the years various pieces of the AA implementation has been templatized and moved to druntime, though the core implementation is still in aaA.d. I think, on the basis of this other work, that we're in a far better position now to fully move AA's into a template implementation. I haven't been keeping track, though, so I don't know what issues might remain that hinder this migration. > Other than that, we've ripped out all other "magic" into templates in > the language. If we could get that one feature (not sure how to do > this in a scalable way), I think we have a full library type that can > be further factored out of the compiler. We might even be able to > avoid using TypeInfo, and make CTFE AAs compatible with runtime ones. [...] Yeah, most of the work on removing AA magic from the compiler has been done by someone else, IIRC Martin Nowak among them, and probably others. Making CTFE AAs usable at runtime is somewhat of a different beast, though. The main problem is that you need to be able to instantiate the binary representation of a runtime AA (the main hash table, and each of the buckets) at compile-time, and do so in a way that the compiler can turn into data in the data segment of the executable. Regardless of what the CTFE representation is, it needs an explicit transformation step to turn it into something the runtime code can decipher. Basically, you have to create an .init value for the final object that doesn't require calling a runtime memory allocation function, but nonetheless still points to legit instances of AA buckets and their contents. This cannot be directly cast from the CTFE AA, because CTFE AA buckets won't have legit runtime addresses that can be assigned to the hash table's pointers. I think this *might* be possible to do via a string mixin that creates explicit variables for each AA bucket then the main hash table by taking their addresses. Of course, some hackish casts will probably be required to make it all work with the current runtime AA implementation. T -- Why can't you just be a nonconformist like everyone else? -- YHL