I want to ask Walter. Few days ago I started a thread about strange (by my opinion) behavior of AA's [] operator (thread was called AA question). From the conversation I thought it's not only my opinion. I doub't Water didn't read that post, but he did not comment. So Walter, please tell me. Why is that AA design? And what is the most important to me - will you change your mind about it and "fix" it in near (or not so near) dmd updates or it is staying this way. I'm asking because I found some bugs in my code based on this behavior I didn't knew about. And now I have to change all my code that uses AA[] operator. And it is lot of code! So I prefer to wait few weeks and do something else in this time rather replacing my [] code with "in"'s and then make it with [] again if current behavior changes...

bobef wrote:

> I want to ask Walter. Few days ago I started a thread about strange (by my
> opinion) behavior of AA's [] operator (thread was called AA question). From the
> conversation I thought it's not only my opinion. I doub't Water didn't read that
> post, but he did not comment. So Walter, please tell me. Why is that AA design?

I am not Walter, but I don't think the AA behaviour is going to change.
It's using the same (weirdo) definition that C++ STL's "std::map" has:

Reading a key that does not exist, inserts an empty value into the hash!

If you don't agree with that behaviour (I'm not sure why anyone would),
you need to use the "in" operator instead - to check if it exists...


Be aware that there's also a related bug, in that it fails to .init:

// "works":
version(INT) alias int TYPE;
version(VOID) alias void* TYPE;

// fails:
version(FLOAT) alias float TYPE;
version(CHAR) alias char TYPE;

int main()
{
  TYPE[int] hash;

  hash[0]; // inserts a key!
  assert(0 in hash); // argh

  assert(hash[0] == TYPE.init);
  return 0;
}

This is in turn related to the default values of the float/char types.
(as they have non-zero .init, but AAs set all automagic values to zero)

But even if the init values of float and char are returned to a more
sane 0.0 and \0, the AAs still inserts new keys when you read them...


I think it sucks too, but it's just how the D hashes work I'm afraid.
--anders


PS. It's mentioned on the list of common questions from C/C++ users:
    http://www.prowiki.org/wiki4d/wiki.cgi?ShortFrequentAnswers

"bobef" <bobef_member@pathlink.com> wrote in message news:d3j2p1$1j32$1@digitaldaemon.com...
>I want to ask Walter. Few days ago I started a thread about strange (by my
> opinion) behavior of AA's [] operator (thread was called AA question).
> From the
> conversation I thought it's not only my opinion. I doub't Water didn't
> read that
> post, but he did not comment. So Walter, please tell me. Why is that AA
> design?
> And what is the most important to me - will you change your mind about it
> and
> "fix" it in near (or not so near) dmd updates or it is staying this way.
> I'm
> asking because I found some bugs in my code based on this behavior I
> didn't knew
> about. And now I have to change all my code that uses AA[] operator. And
> it is
> lot of code! So I prefer to wait few weeks and do something else in this
> time
> rather replacing my [] code with "in"'s and then make it with [] again if
> current behavior changes...

I emailed him last week or so asking for comments about a thread and he said he's been busy fixing dmd-120. I think after he feels more comfortable with dmd-121 he'll chime in. Either that or he'll pull his old trick of letting his code do the talking. It can get frustrating not knowing if he isn't responding because he doesn't agree or if he's just busy but that's how it goes.

I wrote:

> It's using the same (weirdo) definition that C++ STL's "std::map" has:
> 
> Reading a key that does not exist, inserts an empty value into the hash!
> 
> If you don't agree with that behaviour (I'm not sure why anyone would),

Sorry, I forgot the case when you use the hash lookup as an lvalue:

http://www.digitalmars.com/d/arrays.html

            if (inword)
	    {   char[] word = input[wstart .. input.length];
		dictionary[word]++;
	    }

Without it, you would be forced to write:
dictionary[word] = dictionary[word] + 1;

Then again, there's already such a limit
on how you can use the .length property ?

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:d3ja39$1ovt$1@digitaldaemon.com...
>> I am not Walter, but I don't think the AA behaviour is going to change.
> It's using the same (weirdo) definition that C++ STL's "std::map" has:

I suppose it's for non-class AAs.  Think about it - what would attempting to access a nonexistent key do in an int[char[]] array?  Return 0?  Throw an exception?  I suppose it's just for consistency between types.  Though I agree, it is far less intuitive for class AAs to have to use "in".

Jarrett Billingsley wrote:

> I suppose it's for non-class AAs.  Think about it - what would attempting to access a nonexistent key do in an int[char[]] array?  Return 0?

I thought so, but it seems that I was in the minority.

> Throw an exception? 

I think it was Matthew that was suggesting this, earlier ?

> I suppose it's just for consistency between types.  Though I agree, it is far less intuitive for class AAs to have to use "in". 

Whatever the reason, it should be clearly documented - since
it's profoundly confusing to several posters to this newsgroup.

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:d3ja39$1ovt$1@digitaldaemon.com...
> bobef wrote:
>
>> I want to ask Walter. Few days ago I started a thread about
>> strange (by my
>> opinion) behavior of AA's [] operator (thread was called AA
>> question). From the
>> conversation I thought it's not only my opinion. I doub't Water
>> didn't read that
>> post, but he did not comment. So Walter, please tell me. Why is
>> that AA design?
>
> I am not Walter, but I don't think the AA behaviour is going to
> change.
> It's using the same (weirdo) definition that C++ STL's "std::map"
> has:
>
> Reading a key that does not exist, inserts an empty value into the hash!
>
> If you don't agree with that behaviour (I'm not sure why anyone
> would),
> you need to use the "in" operator instead - to check if it
> exists...
>
>
> Be aware that there's also a related bug, in that it fails to .init:
>
> // "works":
> version(INT) alias int TYPE;
> version(VOID) alias void* TYPE;
>
> // fails:
> version(FLOAT) alias float TYPE;
> version(CHAR) alias char TYPE;
>
> int main()
> {
>   TYPE[int] hash;
>
>   hash[0]; // inserts a key!
>   assert(0 in hash); // argh
>
>   assert(hash[0] == TYPE.init);
>   return 0;
> }
>
> This is in turn related to the default values of the float/char
> types.
> (as they have non-zero .init, but AAs set all automagic values to
> zero)
>
> But even if the init values of float and char are returned to a
> more
> sane 0.0 and \0, the AAs still inserts new keys when you read
> them...
>
>
> I think it sucks too, but it's just how the D hashes work I'm
> afraid.
> --anders

For the benefit of bobef, who may be being misled by the lack of response to his concerns, I think it sucks too. I think there are very of us who do not.

But I too doubt it'll change.

"Anders F Björklund" <afb@algonet.se> wrote in message news:d3jseu$29tb$2@digitaldaemon.com...
> Jarrett Billingsley wrote:
>
>> I suppose it's for non-class AAs.  Think about it - what would attempting to access a nonexistent key do in an int[char[]] array?  Return 0?
>
> I thought so, but it seems that I was in the minority.
>
>> Throw an exception?
>
> I think it was Matthew that was suggesting this, earlier ?
>
>> I suppose it's just for consistency between types.  Though I agree, it is far less intuitive for class AAs to have to use "in".
>
> Whatever the reason, it should be clearly documented - since it's profoundly confusing to several posters to this newsgroup.

It's not just the confusion. IMO the built-in AAs are a (syntactic) joke, and I would always have to, in good conscience, caution against their use to any D users, just as I do with auto_ptr<> in C++.

Pretty sad, really.

Matthew wrote:
> "Anders F Björklund" <afb@algonet.se> wrote in message news:d3ja39$1ovt$1@digitaldaemon.com...
> 
>>bobef wrote:
>>
>>
>>>I want to ask Walter. Few days ago I started a thread about strange (by my
>>>opinion) behavior of AA's [] operator (thread was called AA question). From the
>>>conversation I thought it's not only my opinion. I doub't Water didn't read that
>>>post, but he did not comment. So Walter, please tell me. Why is that AA design?
>>
>>I am not Walter, but I don't think the AA behaviour is going to change.
>>It's using the same (weirdo) definition that C++ STL's "std::map" has:
>>
>>Reading a key that does not exist, inserts an empty value into the hash!
>>
>>If you don't agree with that behaviour (I'm not sure why anyone would),
>>you need to use the "in" operator instead - to check if it exists...
>>
>>
>>Be aware that there's also a related bug, in that it fails to .init:
>>
>>// "works":
>>version(INT) alias int TYPE;
>>version(VOID) alias void* TYPE;
>>
>>// fails:
>>version(FLOAT) alias float TYPE;
>>version(CHAR) alias char TYPE;
>>
>>int main()
>>{
>>  TYPE[int] hash;
>>
>>  hash[0]; // inserts a key!
>>  assert(0 in hash); // argh
>>
>>  assert(hash[0] == TYPE.init);
>>  return 0;
>>}
>>
>>This is in turn related to the default values of the float/char types.
>>(as they have non-zero .init, but AAs set all automagic values to zero)
>>
>>But even if the init values of float and char are returned to a more
>>sane 0.0 and \0, the AAs still inserts new keys when you read them...
>>
>>
>>I think it sucks too, but it's just how the D hashes work I'm afraid.
>>--anders
> 
> 
> For the benefit of bobef, who may be being misled by the lack of response to his concerns, I think it sucks too. I think there are very of us who do not.
> 
> But I too doubt it'll change.
> 


Yep. I seriously doubt it also. Particularly so since these 'complaints' have been going strong for a year. The built-in AA does suck. And not just because of the awkward semantics.

To be fair, the one beneficial aspect I can note is the lack of casting required, given that it's a generic container. But then, so what.