On 2/27/20 9:32 AM, Petar Kirov [ZombineDev] wrote:
An example of this is the built-in associative array, which has a
series of
fairly intractable problems as a result. Another example is the built-in
complex type in D, which turned out to be a bad idea - a much better
one is
building it as a library type.
AFAIR, most of the problems with D's built-in AAs are that they have an
extern (C) interface that relies on typeinfo. If they are fully
converted to templated library types, the situation would be much
better. IIRC, one of the blocking issues was that D didn't have
autovivification [1] operators, so a library type wouldn't be a complete
replacement without additional help from the compiler.
We're going very off topic here, but I wanted to address this.
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).
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).
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.
-Steve
