On Tue, 02 Apr 2013 01:59:13 -0400, Luís Marques <luismarq...@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
