Hi.

Associative array automatically add items, if it not existed but was accessed. Small example:

/**************************/
alias char[] string;

void main()
{
string[string] arr;

if("key" in arr)
printf("key exist\n");
else
printf("key not exist\n");

printf("arr[key]=%.*s\n", arr["key"]);

if("key" in arr)
printf("key exist\n");
else
printf("key not exist\n");
}
/**************************/

For DMD 0.109 this program print:

key not exist
arr[key]=
key exist

Item auto inserted after access to it.
Is it feature or bug?
If it is feature - it is very inconveniently.
So i can't trust to 'in' operator.

Sorry, if a missed something.

"novice2" <novice2_member@pathlink.com> wrote in message news:cput9j$2cu8$1@digitaldaemon.com...
> Hi.
>
> Associative array automatically add items, if it not existed but was
accessed.
> Small example:
>
> /**************************/
> alias char[] string;
>
> void main()
> {
> string[string] arr;
>
> if("key" in arr)
> printf("key exist\n");
> else
> printf("key not exist\n");
>
> printf("arr[key]=%.*s\n", arr["key"]);
>
> if("key" in arr)
> printf("key exist\n");
> else
> printf("key not exist\n");
> }
> /**************************/
>
> For DMD 0.109 this program print:
>
> key not exist
> arr[key]=
> key exist
>
> Item auto inserted after access to it.
> Is it feature or bug?
> If it is feature - it is very inconveniently.
> So i can't trust to 'in' operator.
>
> Sorry, if a missed something.
>
>

This is how it is documented to work. The precedent is C++'s map class. The alternative is to throw an exception and my guess for why it doesn't is that maybe having a function that sometimes throws is slower than always inserting. It does seem a little wierd but it isn't unreasonable.

-Ben

This is, unfortunately, how the thing is designed to work.

Look at
	<expr> in <assoc_array>
which returns null if the element doesn't exist, and a pointer to the element otherwise.

novice2 wrote:
> Hi.
> 
> Associative array automatically add items, if it not existed but was accessed.
> Small example:
> 
> /**************************/
> alias char[] string;
> 
> void main()
> {
> string[string] arr;
> 
> if("key" in arr)
> printf("key exist\n");
> else
> printf("key not exist\n");
> 
> printf("arr[key]=%.*s\n", arr["key"]);
> 
> if("key" in arr)
> printf("key exist\n");
> else
> printf("key not exist\n");
> }
> /**************************/
> 
> For DMD 0.109 this program print:
> 
> key not exist
> arr[key]=
> key exist
> 
> Item auto inserted after access to it.
> Is it feature or bug?
> If it is feature - it is very inconveniently.
> So i can't trust to 'in' operator.
> 
> Sorry, if a missed something.
> 
> 

This is a very bad behavior and should be corrected. I know it is a feature, but a very bad one!

Everything else should work as it is (for example if someone reads an nonexisting value then a default value is returned.) But reading must not actually create the element. Reading is reading and writing is writing. If we don't care that D is a logical, easy to use and easy to understand language, then why don't we all use Java or something else?

Why spoil the D language?

I truly hope you change it!
(Ok for bakward compatiblity there can be a switch to switch between the on and
another behavior.)


In article <cpuuir$2e66$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"novice2" <novice2_member@pathlink.com> wrote in message news:cput9j$2cu8$1@digitaldaemon.com...
>> Hi.
>>
>> Associative array automatically add items, if it not existed but was
>accessed.
>> Small example:
>>
>> /**************************/
>> alias char[] string;
>>
>> void main()
>> {
>> string[string] arr;
>>
>> if("key" in arr)
>> printf("key exist\n");
>> else
>> printf("key not exist\n");
>>
>> printf("arr[key]=%.*s\n", arr["key"]);
>>
>> if("key" in arr)
>> printf("key exist\n");
>> else
>> printf("key not exist\n");
>> }
>> /**************************/
>>
>> For DMD 0.109 this program print:
>>
>> key not exist
>> arr[key]=
>> key exist
>>
>> Item auto inserted after access to it.
>> Is it feature or bug?
>> If it is feature - it is very inconveniently.
>> So i can't trust to 'in' operator.
>>
>> Sorry, if a missed something.
>>
>>
>
>This is how it is documented to work. The precedent is C++'s map class. The alternative is to throw an exception and my guess for why it doesn't is that maybe having a function that sometimes throws is slower than always inserting. It does seem a little wierd but it isn't unreasonable.
>
>-Ben
>
>

Martin wrote:
> This is a very bad behavior and should be corrected. I know it is a feature, but a very bad one!

Do you mean you've weighed up the pros and cons?  On practical grounds, not just puristic ones?

<snip>
> I truly hope you change it!
> (Ok for bakward compatiblity there can be a switch to switch between the on and another behavior.)
<snip top of upside-down reply>

I think D is still planning to be one standardised language, not two subtly different, mutually incompatible languages.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Ben Hinkle wrote:

> This is how it is documented to work. The precedent is C++'s map class. The
> alternative is to throw an exception and my guess for why it doesn't is that
> maybe having a function that sometimes throws is slower than always
> inserting. It does seem a little wierd but it isn't unreasonable.

Where is this documented, by the way ?
(Couldn't find it on the page about Associative Arrays:
http://www.digitalmars.com/d/arrays.html#associative ?)

I guess the default initializer is used for clearing
the entry that one tries to access ? (When I tested,
it set the values of strings to "" and integers to 0)

Too bad that "in" still returns bit, on DMD 0.102 (GDC).

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:cpv4vd$2ll9$1@digitaldaemon.com...
> Ben Hinkle wrote:
>
> > This is how it is documented to work. The precedent is C++'s map class.
The
> > alternative is to throw an exception and my guess for why it doesn't is
that
> > maybe having a function that sometimes throws is slower than always inserting. It does seem a little wierd but it isn't unreasonable.
>
> Where is this documented, by the way ?
> (Couldn't find it on the page about Associative Arrays:
> http://www.digitalmars.com/d/arrays.html#associative ?)

Hmm. I guess I was mistaken. I can't find it either. sorry about that!

> I guess the default initializer is used for clearing
> the entry that one tries to access ? (When I tested,
> it set the values of strings to "" and integers to 0)
>
> Too bad that "in" still returns bit, on DMD 0.102 (GDC).
>
> --anders

Based on the implementation of Java's Map, it seems more reasonable to me that arr["key"] should return null in the printf() example provided.  How can reading the value create a value, and what value is created?

After the printf(), does arr["key"] == null?  This sure looks like a bug to me.


>> alias char[] string;
>>
>> void main()
>> {
>> string[string] arr;
>>
>> if("key" in arr)
>> printf("key exist\n");
>> else
>> printf("key not exist\n");
>>
>> printf("arr[key]=%.*s\n", arr["key"]);
>>
>> if("key" in arr)
>> printf("key exist\n");
>> else
>> printf("key not exist\n");
>> }
>> /**************************/
>>
>> For DMD 0.109 this program print:
>>
>> key not exist
>> arr[key]=
>> key exist

Garett Bass wrote:

> Based on the implementation of Java's Map, it seems more reasonable to me that arr["key"] should return null in the printf() example provided.  How can reading the value create a value, and what value is created?

Reading the value creates the default initialized value...

i.e. "" for strings and 0 for integers (see the type list)

> After the printf(), does arr["key"] == null?  This sure looks like a bug to me.

Both in the printf and afterwards, the key becomes set.

Only ("key" in arr) checks it, without modifying it too.


I also think it's a bug. (it should return null, not set it!)

--anders

IMHO access to not existing items in associative array should throw exception
"Out of bounds", like to access to not existing items in normal arrays.
IMHO auto creating not existing items is confuse. It is bad side effect.

For me disabling autocreating will have no pros (?) and some cons (better error
detection).

good luck
novice2.

In article <cpuuir$2e66$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"novice2" <novice2_member@pathlink.com> wrote in message news:cput9j$2cu8$1@digitaldaemon.com...
>> Hi.
>>
>> Associative array automatically add items, if it not existed but was
>accessed.
>> Small example:
>>
>> /**************************/
>> alias char[] string;
>>
>> void main()
>> {
>> string[string] arr;
>>
>> if("key" in arr)
>> printf("key exist\n");
>> else
>> printf("key not exist\n");
>>
>> printf("arr[key]=%.*s\n", arr["key"]);
>>
>> if("key" in arr)
>> printf("key exist\n");
>> else
>> printf("key not exist\n");
>> }
>> /**************************/
>>
>> For DMD 0.109 this program print:
>>
>> key not exist
>> arr[key]=
>> key exist
>>
>> Item auto inserted after access to it.
>> Is it feature or bug?
>> If it is feature - it is very inconveniently.
>> So i can't trust to 'in' operator.
>>
>> Sorry, if a missed something.
>>
>>
>
>This is how it is documented to work. The precedent is C++'s map class. The alternative is to throw an exception and my guess for why it doesn't is that maybe having a function that sometimes throws is slower than always inserting. It does seem a little wierd but it isn't unreasonable.
>
>-Ben
>
>