More magical AA semantics

[Don]

On Friday, 11 January 2013 at 09:20:13 UTC, Jonathan M Davis 
wrote:
> On Friday, January 11, 2013 10:03:54 Don wrote:
>> That's my feeling too. I think that if we want to implement AAs
>> as a library type, we first need to eliminate all of the
>> semantics would be impossible to implement in a library.
>
> Well, the AAs are _already_ a library type. That's a large part 
> of why they
> have so many bugs. The transition to a library type was badly 
> done, and we
> sorely need a new implementation. Also, because the compiler is 
> generating
> hooks that druntime plugs into, the built-in AAs aren't 
> restricted to quite
> the same semantics that a user-defined AA type would be, even 
> though the AAs
> are implemented in druntime instead of the compiler.


Unfortunately, that's not true. All that happened was that a 
template layer was added on top of the built-in implementation. 
The compiler still knows intimate details about the 
implementation. The number of hooks from the compiler to the 
runtime have not decreased; in fact, they have increased.

AFAIK there is not a single place in the compiler where coupling 
between compiler and runtime decreased. There are very many 
places where it got much more complicated.


> So, AFAIK, we don't really have a problem with the built-in AAs 
> doing stuff
> that a library type can't do (that's not even possible at this 
> point, because
> they're implemented with a library type).

It's not a library type in a meaningful sense. The semantics come 
almost entirely from the compiler, not from the library. There's 
almost nothing in the implementation that can be changed without 
changing the compiler.