"David Medlock" <noone@nowhere.com> wrote in message news:daml32$o2a$1@digitaldaemon.com...
> Oh well..
> -DavidM

I wish you'd spoken up sooner. I don't remember a single person defending the former behavior of aa's.

Andrew Fedoniouk wrote:
> "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.
> 
> 
Less code, but yes the same:


struct A { int n = 0; }
A[char[]] aa;

void set(  char[] key, int val )
{
  A  var;
  if ( aa.get( key, var ) )  var.n = val;
}

// versus

void set( char[] key, int val )
{
  A* ptr = (key in aa );
  if ( a is null )
  {
    A temp;
    temp.n = val;
    aa[key] = temp;
  }
  else ptr.n = val;
}

Sorry, I wasn't clear on that.

If you allow it to create the out parameter, you get the old behavior, plus you get the information whether or not it was created!

if ( aa.get( 100, var ) ) { ...key was in aa...}
else { ...key was not in aa, do something with var... }

This seems like a good addition if the new semantics are retained.

-DavidM

Walter wrote:

>>Oh well..
>>-DavidM
> 
> I wish you'd spoken up sooner. I don't remember a single person defending
> the former behavior of aa's.

I hope we are not "designing by committee" here,
because I don't think the new AA is much better...
(and 'in' returning a pointer is still a tad weird)

i.e. to me it doesn't make much of a difference if
a lookup secretly inserts a value, or if a missing
key makes it throw up an exception on the carpet ?


And all of this "let's add a method to do it" makes you
wonder if we wouldn't all be better off with a library
implementation of AAs ? I like the built-in AAs a lot,
but if we can't make the syntax "OK" and if you can't
initialize them in a simple and pretty way - then why ?

As in: I would rather have any old horse, than a new camel.

--anders

PS. I'm still hoping we can fix them, and leave them in ?
    Built-in arrays and tables are *very* useful to have.

"Anders F Björklund" <afb@algonet.se> wrote in message news:dao0rm$1q6p$1@digitaldaemon.com...
> PS. I'm still hoping we can fix them, and leave them in ?
>      Built-in arrays and tables are *very* useful to have.

Yes, I totally agree with that. I often get the "C++ is better because it does it with a library", but there are significant advantages to building it into the core. I use them a lot in my own D programming, and they're a big win.

Where I screwed up, though, are the bit arrays <g>. If I was doing D over, I'd leave them out. They aren't worth the trouble.

> Where I screwed up, though, are the bit arrays <g>. If I was doing D over, I'd leave them out. They aren't worth the trouble.

Well, why don't you leave them out now? We could make a poll in the newsgroup (just a *suggestion* for now!):

1. Will you need bit arrays in the future?
2. Did you already use bit arrays in some important piece of code?

Perhaps they are unpopular, und all your problems will be solved...  ;o)

Ciao
uwe

"Uwe Salomon" <post@uwesalomon.de> wrote in message news:op.stnv8yzj6yjbe6@sandmann.maerchenwald.net...
> > Where I screwed up, though, are the bit arrays <g>. If I was doing D over, I'd leave them out. They aren't worth the trouble.
>
> Well, why don't you leave them out now? We could make a poll in the newsgroup (just a *suggestion* for now!):
>
> 1. Will you need bit arrays in the future?
> 2. Did you already use bit arrays in some important piece of code?
>
> Perhaps they are unpopular, und all your problems will be solved...  ;o)

I know that Stewart uses them a lot.

>> Perhaps they are unpopular, und all your problems will be solved...  ;o)
>
> I know that Stewart uses them a lot.

Oh my! Stewart, how could you do that to us?! ;o)

Ciao
uwe

Walter wrote:

>>PS. I'm still hoping we can fix them, and leave them in ?
>>     Built-in arrays and tables are *very* useful to have.
> 
> Yes, I totally agree with that. I often get the "C++ is better because it
> does it with a library", but there are significant advantages to building it
> into the core. I use them a lot in my own D programming, and they're a big
> win.

I can only compare with C or Java, but I do think the syntax
is nicer when they are built-in to the core language itself.

But that could be since I've been doing Perl for ten years,
where the @arrays and %hashes are as natural as $scalars ? :-)

--anders

Walter wrote:
> "Anders F Björklund" <afb@algonet.se> wrote in message
> news:dao0rm$1q6p$1@digitaldaemon.com...
> 
>>PS. I'm still hoping we can fix them, and leave them in ?
>>     Built-in arrays and tables are *very* useful to have.
> 
> 
> Yes, I totally agree with that. I often get the "C++ is better because it
> does it with a library", but there are significant advantages to building it
> into the core. I use them a lot in my own D programming, and they're a big
> win.
> 
> Where I screwed up, though, are the bit arrays <g>. If I was doing D over,
> I'd leave them out. They aren't worth the trouble.
> 
> 

If you don't mind me asking, what are wrong with the bit arrays?

"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?

I assume you mean an example like
import mintl.list;
int main() {
  List!(int)[char[]] x;
  x["hello"] ~= 10;
}
The x["hello"] is treated as an rvalue instead of an lvalue when ~= gets
converted to opCatAssign. I would consider that another bug in AA's
indexing.