Implicit dereferencing

[Steven Schveighoffer]

On Tue, 02 Apr 2013 01:59:13 -0400, Luís Marques <luismarques at gmail.com>  
wrote:

> On Tuesday, 2 April 2013 at 04:48:54 UTC, Steven Schveighoffer wrote:
>> HOWEVER, there is one horrible caveat.  You must have assigned an  
>> element at least once in order to alias:
>
> Thanks Steve, I had already looked into that, but then got dense and I  
> was treating the AA as having value semantics. I don't need the pointer.
>
> Is there a way to ensure the AA is initialized as not null, besides  
> adding and removing an element? (I couldn't use a literal)

Not sure.  Looking...  can't find anything.

So no.  There really should be.

> Is the null initializer a consequence of the current opaque  
> implementation, or just of the reference semantics? (I saw on the wiki  
> that there was a desire to use a less opaque implementation. I think the  
> AA ABI should be documented, like the other arrays)

The AA ABI is defined by druntime in object.di.  AA's are currently a  
hybrid between a compiler-magic type and a template.  The plan is to make  
it completely a template, that is, the compiler simply always treats T[U]  
as AssociativeArray!(T, U).

The null initializer is a result of D's policy on struct initialization.   
Default constructors are not allowed on structs, they must be able to be  
initialized with static data when declared without a constructor.

> Slightly related, it doesn't seem very reasonable to me that the get  
> method of AAs is not safe:
>
> @safe:
>
> void main()
> {
>      int[string] x;
>      x.get("b", 0);
> }
>
> Error: safe function 'D main' cannot call system function  
> 'object.AssociativeArray!(string, int).AssociativeArray.get'

Someone (can't remember who) went through a lot of effort to try and  
re-implement AAs as object.AssociativeArray and ran into a lot of problems  
with things like @safe and pure.  It really should be @safe, but I don't  
know if there was a specific reason why it wasn't tagged that way.

-Steve