• Gilles G. (18/18) Jul 10 2007 Hello,
• Robert Fraser (4/26) Jul 10 2007 Possibly related to this:
• Chris Nicholson-Sauls (6/28) Jul 10 2007 I would say this is because, until /assigned to/, AA pairs "don't
• Chris Nicholson-Sauls (9/42) Jul 13 2007 Which later made me think of something. Might it be useful for AA's to

Gilles G. <schaouette free.fr> writes:

Hello,
I am just wondering why we should use init for associative arrays of structs.
See this code for example:
    struct S
    {
        int nb;
    }
    void main()
    {
        S[char[]] aa; // associative array of struct S
        aa["this_is_good"] = S.init;
        aa["this_is_good"].nb = 1;      // all right
        aa["this_is_an_error"].nb = 1; // runtime error, compiles fine...
    }

I can't see a use case for _not_ using init before accessing a new key, so why
do we have to explicitely use S.init?
Why does this code compile fine (it gives an access violation error at
runtime), shouldn't it always give an error?

Regards.

--
Gilles

Robert Fraser <fraserofthenight gmail.com> writes:

Possibly related to this:
http://d.puremagic.com/issues/show_bug.cgi?id=1315

Try with a runtime value.

Gilles G. Wrote:

 Hello,
 I am just wondering why we should use init for associative arrays of structs.
See this code for example:
     struct S
     {
         int nb;
     }
     void main()
     {
         S[char[]] aa; // associative array of struct S
         aa["this_is_good"] = S.init;
         aa["this_is_good"].nb = 1;      // all right
         aa["this_is_an_error"].nb = 1; // runtime error, compiles fine...
     }
 
 I can't see a use case for _not_ using init before accessing a new key, so why
do we have to explicitely use S.init?
 Why does this code compile fine (it gives an access violation error at
runtime), shouldn't it always give an error?
 
 Regards.
 
 --
 Gilles
 

Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:

Gilles G. wrote:
 Hello,
 I am just wondering why we should use init for associative arrays of structs.
See this code for example:
     struct S
     {
         int nb;
     }
     void main()
     {
         S[char[]] aa; // associative array of struct S
         aa["this_is_good"] = S.init;
         aa["this_is_good"].nb = 1;      // all right
         aa["this_is_an_error"].nb = 1; // runtime error, compiles fine...
     }
 
 I can't see a use case for _not_ using init before accessing a new key, so why
do we have to explicitely use S.init?
 Why does this code compile fine (it gives an access violation error at
runtime), shouldn't it always give an error?
 
 Regards.
 
 --
 Gilles
 

I would say this is because, until /assigned to/, AA pairs "don't 
exist."  Since the member-access of the dot operator occurs "before" the 
member-assignment, there is an attempt to dereference null.  The `= 
S.init` idiom is just a convenient way to insert the new AA value.

-- Chris Nicholson-Sauls

Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:

Chris Nicholson-Sauls wrote:
 Gilles G. wrote:
 Hello,
 I am just wondering why we should use init for associative arrays of 
 structs. See this code for example:
     struct S
     {
         int nb;
     }
     void main()
     {
         S[char[]] aa; // associative array of struct S
         aa["this_is_good"] = S.init;
         aa["this_is_good"].nb = 1;      // all right
         aa["this_is_an_error"].nb = 1; // runtime error, compiles fine...
     }

 I can't see a use case for _not_ using init before accessing a new 
 key, so why do we have to explicitely use S.init?
 Why does this code compile fine (it gives an access violation error at 
 runtime), shouldn't it always give an error?

 Regards.

 -- 
 Gilles

 
 I would say this is because, until /assigned to/, AA pairs "don't 
 exist."  Since the member-access of the dot operator occurs "before" the 
 member-assignment, there is an attempt to dereference null.  The `= 
 S.init` idiom is just a convenient way to insert the new AA value.
 
 -- Chris Nicholson-Sauls

Which later made me think of something.  Might it be useful for AA's to 
explose a .add(K) counterpart to the existing .remove(K) property? 
Usage being as follows:

V[K] aa ;
aa.add(K, someValue); // equivelant to 'aa[K] = someValue'
aa.add(K); // equivelant to 'aa[K] = V.init'

Or did something like this come along and I missed it?

-- Chris Nicholson-Sauls