"Nick" <Nick_member@pathlink.com> wrote in message news:damdj8$h06$1@digitaldaemon.com...
> 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

I wouldn't mind seeing more explicit names for the indexing behaviors like "get","add","insert" whatever and then have indexing do what it currently does (assuming the bugs get fixed) - pick the best function depending on rvalue/lvalue needs. I would bet that if the AA indexing bugs weren't there none of these recent threads about indexing would have come up because it just does what is natural.

On Sat, 09 Jul 2005 14:52:23 -0400, Walter <newshound@digitalmars.com> wrote:

> 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.

I don't use bit arrays or pointers-to-bit because they seem to be screwed up, but I do like using regular old bit variables since I like that the compiler can pack them together.

What if there were some rules about bit arrays and pointers:
   1) Can only slice or take address on byte boundaries, otherwise an exception is thrown.
   2) To slice or take address on non-byte boundaries, you'd have to use a special method, perhaps:
         bitarray.dup(1, 2)
      to create a new slice of bitarray[1 .. 2].
This means bit* will actually be byte* internally.

Are there other problems with bit?

"Walter" <newshound@digitalmars.com> wrote in message news:dap6pp$2sv5$1@digitaldaemon.com...
>
> "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.
>
>

Yep. Bit arrays is a dark corner now.

May I suggest to replace them with some templated struct in Phobos?

Sort of:

struct bitset( uint numBits )
{
   static if (numBits <= 16)
      ushort data;
   static else if (numBits <= 32)
      uint data;
   static else
      uint[ numBits / 32 ] data;
   ....
   opIndexAssign() ...
   opIndex() ...
}

"Walter" <newshound@digitalmars.com> wrote in message news:damt98$v3j$1@digitaldaemon.com...
>
> "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.

If you change something and no-one complains it means you don't have enough users :-)

<g> That's a great quote on so many levels. :)

In article <db1449$198j$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"Walter" <newshound@digitalmars.com> wrote in message news:damt98$v3j$1@digitaldaemon.com...
>>
>> "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.
>
>If you change something and no-one complains it means you don't have enough users :-)
>
>