Possible D2 solution to the upcasting array problem, and a related

[Stewart Gordon]

Luther Tychonievich wrote:
> Stewart Gordon Wrote:
> 
>> That leaves AAs to consider....
> 
> I can't find any conceptual difference here between any type of 
> indirection: pointers, "ref" variables, static arrays, dynamic
> arrays, associative arrays, even aggregate types if the typing engine
> bothered with them:

Static arrays aren't a type of indirection.  They have value semantics. 
  Hence const(char[26]) and const(char)[26] are identical.  (There seems 
to be a bug at the moment whereby DMD treats them as different types.)

<snip>
> Associative arrays are conceptually aggregates of two types (key and
> value), and both should follow the safe upcasting rules; in practice,
> however, the implementation (at least dmd 2.022) automatically
> const-s all but the outermost level of indirection within the key
> type, such that "int[int[]]" parses as "int[const(int)[]]", so the
> rule will never rule out a key type.

So effectively, key types are implicitly tail-consted.

> (incidentally, I just noticed that the AA initializer expression
> "[[1]:2]" won't parse in dmd...)
> 
> There may be some  subtleties to the "all objects are implicitly
> pointers" rule (implying that class types are a kind of indirection),
> but at first glance they seem to be avoided because const-ness cannot
> get inside that implicit pointer.

Indeed, classes used as AA keys seem to be mutable by default.  But this 
does seem to be an inconsistency.

There is std.typecons.Rebindable.  But ISTM mainly a syntax deficiency 
that this can't be expressed as a D builtin.

Stewart.