In the main newsgroup someone noticed that
int main() {
  int[char[]] x;
  int* p = &x["hello"];
  return 0;
}
errors that "hello" is not in the array. I think it is a bug and that &
should force "hello" to be inserted if not present.

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:dam0hb$5ds$1@digitaldaemon.com...
> In the main newsgroup someone noticed that
> int main() {
>  int[char[]] x;
>  int* p = &x["hello"];
>  return 0;
> }
> errors that "hello" is not in the array. I think it is a bug and that &
> should force "hello" to be inserted if not present.

Umm, isn't that behavior that was just changed in 0.126?

Jarrett Billingsley wrote:

> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:dam0hb$5ds$1@digitaldaemon.com...
> 
>>In the main newsgroup someone noticed that
>>int main() {
>> int[char[]] x;
>> int* p = &x["hello"];
>> return 0;
>>}
>>errors that "hello" is not in the array. I think it is a bug and that & should force "hello" to be inserted if not present.
> 
> 
> Umm, isn't that behavior that was just changed in 0.126? 
> 
> 
I guess I missed the conversation about this, but I don't see a single advantage to making the common case(default insertion) the most difficult option with AAs.

If the key may not exist in the AA you can still use in, but now the simple option of inserting a default value requires much hoop jumping.

Can someone enlighten me the thinking behind this?

In article <dambvi$fih$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:dam0hb$5ds$1@digitaldaemon.com...
>> In the main newsgroup someone noticed that
>> int main() {
>>  int[char[]] x;
>>  int* p = &x["hello"];
>>  return 0;
>> }
>> errors that "hello" is not in the array. I think it is a bug and that &
>> should force "hello" to be inserted if not present.
>
>Umm, isn't that behavior that was just changed in 0.126?

The idea is that the & operator expects an lvalue, and the AA inserts an element whenever an lvalue is required.

Personally I'm more getting inclined towards an .add() property, which would always return a valid element. Having all these special cases to remember is not a Good Thing, IMHO.

Nick

"David Medlock" <noone@nowhere.com> wrote in message news:damcu4$gb1$1@digitaldaemon.com...
> Jarrett Billingsley wrote:
>
>> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:dam0hb$5ds$1@digitaldaemon.com...
>>
>>>In the main newsgroup someone noticed that
>>>int main() {
>>> int[char[]] x;
>>> int* p = &x["hello"];
>>> return 0;
>>>}
>>>errors that "hello" is not in the array. I think it is a bug and that &
>>>should force "hello" to be inserted if not present.
>>
>>
>> Umm, isn't that behavior that was just changed in 0.126?
> I guess I missed the conversation about this, but I don't see a single advantage to making the common case(default insertion) the most difficult option with AAs.

Search for threads in the main newsgroup with titles like 'in stinks' and 'aa' or 'AA'. I see about 3 or 4 threads about insert-on-lookup behavior or other AA behaviors like 'in', 'delete', 'contains', etc

> If the key may not exist in the AA you can still use in, but now the simple option of inserting a default value requires much hoop jumping.
>
> Can someone enlighten me the thinking behind this?

There were many suggestions to Walter about what to do about AAs. IMHO he's done a few of the changes but more is needed.

Ben Hinkle wrote:

> "David Medlock" <noone@nowhere.com> wrote in message news:damcu4$gb1$1@digitaldaemon.com...
> 
>>Jarrett Billingsley wrote:
>>
>>
>>>"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:dam0hb$5ds$1@digitaldaemon.com...
>>>
>>>
>>>>In the main newsgroup someone noticed that
>>>>int main() {
>>>>int[char[]] x;
>>>>int* p = &x["hello"];
>>>>return 0;
>>>>}
>>>>errors that "hello" is not in the array. I think it is a bug and that & should force "hello" to be inserted if not present.
>>>
>>>
>>>Umm, isn't that behavior that was just changed in 0.126?
>>
>>I guess I missed the conversation about this, but I don't see a single advantage to making the common case(default insertion) the most difficult option with AAs.
> 
> 
> Search for threads in the main newsgroup with titles like 'in stinks' and 'aa' or 'AA'. I see about 3 or 4 threads about insert-on-lookup behavior or other AA behaviors like 'in', 'delete', 'contains', etc

Odd, considering automatic insertion is the default for std::map's operator[]...

There are 3 basic situations with a map:

1. I have a value which I absolutely must insert into the map.
2. I wish to see if the value exists in the map, if it doesnt do action
A else do Action B.
3. I wish to see if the value exists in the map, if it doesnt then add a value, then perform some actions on that entry.


#1 is unaffected by the change.
#2 is well covered by *in*
#3 is the overriding default for structs and especially arrays.

Before you could use *in* for the special case where you had an AA and did not wish to insert (struct or array only, since classes are by reference).  Now you are forced to use *in* for #3 for these types on every access.

For :

int[][ char c ]  myAA;

I cannot just use the elegant:

myAA['x'] ~= 100;

now it is:

int[]* ptr = ('x' in myAA);
if ( ptr is null )
{
  ptr[0] = new int[1];
  myAA['x'] = ptr[0];
}
ptr[0] ~= 100;


And this is considered a good thing?  By what standards is the second case more readable, and maintainable ?

So saving a few machine cycles for the corner case where you do not want to auto-insert is the rationale?  Isn't that covered by *in*?

> 
>>If the key may not exist in the AA you can still use in, but now the simple option of inserting a default value requires much hoop jumping.
>>
>>Can someone enlighten me the thinking behind this?
> 
> 
> There were many suggestions to Walter about what to do about AAs. IMHO he's done a few of the changes but more is needed. 
> 

I fear D is fast losing its 'simplicity' compared to C++.
Programmer time is *always* more valuable than machine time.

-DavidM

> For :
>
> int[][ char c ]  myAA;
>
> I cannot just use the elegant:
>
> myAA['x'] ~= 100;

That works just fine. For example try running
int main() {
    int[][char[]] x;
    x["hello"] ~= 10;
    x["hello"] ~= 20;
    x["world"] ~= 30;
    printf("length %d\n",x.length);
    return 0;
}

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:dam0hb$5ds$1@digitaldaemon.com...
> In the main newsgroup someone noticed that
> int main() {
>  int[char[]] x;
>  int* p = &x["hello"];
>  return 0;
> }
> errors that "hello" is not in the array. I think it is a bug and that &
> should force "hello" to be inserted if not present.
>
>

Probably immutables might also help in this situation

int foo( inout int #[char[]] x )
{
  int *p = &x["hello"]; // returns null
  return 0;
}

int foo( inout int [char[]] x )
{
  int *p = &x["hello"]; // returns valid pointer
  return 0;
}

No?

Ben Hinkle wrote:
>>For :
>>
>>int[][ char c ]  myAA;
>>
>>I cannot just use the elegant:
>>
>>myAA['x'] ~= 100;
> 
> 
> That works just fine. For example try running
> int main() {
>     int[][char[]] x;
>     x["hello"] ~= 10;
>     x["hello"] ~= 20;
>     x["world"] ~= 30;
>     printf("length %d\n",x.length);
>     return 0;
> }
> 
> 

True.
However replacing int[] with a struct like your List!(int) will cause it to fail.  This disallows replacing an int[] with a container, doesn't it?

My question still remains, which instances are better because off with this change?

I don't see any improvement in the *dont create* case, compared with the previous situation.

But this adds complexity in the *insert and give me the default* case. (which I would argue is more often used)

A better solution would be keep STL like behavior, and add a builtin:

  bool get( in Key key, out Value val )

method to all AAs.  This would return true if it was found, and store the value in val.

Oh well..
-DavidM

"David Medlock" <noone@nowhere.com> wrote in message news:daml32$o2a$1@digitaldaemon.com...
> Ben Hinkle wrote:
>>>For :
>>>
>>>int[][ char c ]  myAA;
>>>
>>>I cannot just use the elegant:
>>>
>>>myAA['x'] ~= 100;
>>
>>
>> That works just fine. For example try running
>> int main() {
>>     int[][char[]] x;
>>     x["hello"] ~= 10;
>>     x["hello"] ~= 20;
>>     x["world"] ~= 30;
>>     printf("length %d\n",x.length);
>>     return 0;
>> }
>>
>>
>
> True.
> However replacing int[] with a struct like your List!(int) will cause it
> to fail.  This disallows replacing an int[] with a container, doesn't it?
>
> My question still remains, which instances are better because off with this change?
>
> I don't see any improvement in the *dont create* case, compared with the previous situation.
>
> But this adds complexity in the *insert and give me the default* case. (which I would argue is more often used)
>
> A better solution would be keep STL like behavior, and add a builtin:
>
>   bool get( in Key key, out Value val )
>
> method to all AAs.  This would return true if it was found, and store the value in val.

"bool get( in Key key, out Value val )"

This is what 'in' is doing.currently. Isn't it?

Andrew.