On Saturday, January 12, 2013 13:46:57 monarch_dodra wrote:
> On Saturday, 12 January 2013 at 12:41:12 UTC, Jonathan M Davis
> 
> wrote:
> > My gripe with
> > something like ++a[0] working when there's no a[0] is that
> > you'd be adding to
> > an element that doesn't exist yet.
> > 
> > - Jonathan M Davis
> 
> Not to mention, if "++" throws, I bet you'd insert T.init in a[0]. I don't see it behaving any other way.

Which is precisely one of the AA bugs that I'm most annoyed with:

aa[0] = funcThatThrows();

inserts T.init at aa[0].

- Jonathan M Davis

On Saturday, 12 January 2013 at 12:52:43 UTC, Jonathan M Davis wrote:
> On Saturday, January 12, 2013 13:46:57 monarch_dodra wrote:
>> On Saturday, 12 January 2013 at 12:41:12 UTC, Jonathan M Davis
>> 
>> wrote:
>> > My gripe with
>> > something like ++a[0] working when there's no a[0] is that
>> > you'd be adding to
>> > an element that doesn't exist yet.
>> > 
>> > - Jonathan M Davis
>> 
>> Not to mention, if "++" throws, I bet you'd insert T.init in
>> a[0]. I don't see it behaving any other way.
>
> Which is precisely one of the AA bugs that I'm most annoyed with:
>
> aa[0] = funcThatThrows();
>
> inserts T.init at aa[0].
>
> - Jonathan M Davis

Well, it looks like this is fixed in 9rnsr's pull. I'll ask him directly regarding "++".

On Sat, Jan 12, 2013 at 04:40:16AM -0800, Jonathan M Davis wrote:
> On Saturday, January 12, 2013 13:30:47 monarch_dodra wrote:
[...]
> > What about "++a[0]" when there is no a[0]? Is this something that will throw or not?
> 
> Personally, I think that it should, but there's probably a good chance that it won't, because it's an lvalue. I don't know what will happen with that though.  There are a lot of bugs right now related elements being inserted into AAs when they shouldn't be, so I really don't know how much relation the current behavior will have with the behavior that AAs will ultimately have.

Yeah, like:

	http://d.puremagic.com/issues/show_bug.cgi?id=3825
	http://d.puremagic.com/issues/show_bug.cgi?id=4463
	http://d.puremagic.com/issues/show_bug.cgi?id=5234
	http://d.puremagic.com/issues/show_bug.cgi?id=6178
	http://d.puremagic.com/issues/show_bug.cgi?id=8170


> > As well, what about
> > //----
> > immutable(int)[int] aa;
> > aa[0] = 5;
> > //----
> > This should work, right?
> 
> That should definitely work. That's how you add elements to AA. My gripe with something like ++a[0] working when there's no a[0] is that you'd be adding to an element that doesn't exist yet.
[...]

I think issue 4463 shows that ++a[0] produces 1.0 for a double[int], which is totally wrong (it should be nan, if it's even allowed in the first place).

The main problem is that the current AA code in aaA.d has no information on the value types, so a lot of things are done by binary instead of by type information. So .init is wrongly conflated with the equivalent of memset(0), opEquals is wrongly conflated with binary equality, etc., etc.. Basically, it's a fractal of brokenness that just happens to work in enough common cases that it barely avoids being unusably frustrating.


T

-- 
Skill without imagination is craftsmanship and gives us many useful objects such as wickerwork picnic baskets.  Imagination without skill gives us modern art. -- Tom Stoppard

On 1/12/13 5:51 AM, monarch_dodra wrote:
> On Saturday, 12 January 2013 at 04:24:01 UTC, deadalnix wrote:
>> On Friday, 11 January 2013 at 13:50:33 UTC, monarch_dodra wrote:
>>> I find that with LTR, you end up with a value (T.init), that you
>>> never actually put into your array. IMO, that means something went
>>> wrong somewhere. This is particularly relevant with "++a[0]".
>>>
>>
>> Not necessarily, as the computation made for an assignation isn't the
>> one made in order to get the value.
>>
>> It make sense that such expression fail. As long as the AA as the key
>> are computed before the value and in that order.
>
> I guess I can see it either way. My only gripe though is that:
> "a[0] = a[0] + 5;"
>
> Could never work if AA's were a "true" library type. I think this is a
> problem, if the plan is to one day completely move AA's out of the
> compiler.
>
> That, and for generic programming, it means my user written HashMap!
> will never be able to have AA's semantics.

But a[0] += 5 can be made to work.

Andrei

On 1/12/13 7:40 AM, Jonathan M Davis wrote:
> On Saturday, January 12, 2013 13:30:47 monarch_dodra wrote:
>> What about "++a[0]" when there is no a[0]? Is this something that
>> will throw or not?
>
> Personally, I think that it should, but there's probably a good chance that it
> won't, because it's an lvalue. I don't know what will happen with that though.
> There are a lot of bugs right now related elements being inserted into AAs
> when they shouldn't be, so I really don't know how much relation the current
> behavior will have with the behavior that AAs will ultimately have.

++a[0] should work.

>> As well, what about
>> //----
>> immutable(int)[int] aa;
>> aa[0] = 5;
>> //----
>> This should work, right?
>
> That should definitely work. That's how you add elements to AA. My gripe with
> something like ++a[0] working when there's no a[0] is that you'd be adding to
> an element that doesn't exist yet.

Shouldn't work.

Andrei

On Saturday, 12 January 2013 at 21:56:13 UTC, Andrei Alexandrescu wrote:
> On 1/12/13 7:40 AM, Jonathan M Davis wrote:
>> On Saturday, January 12, 2013 13:30:47 monarch_dodra wrote:
>>> What about "++a[0]" when there is no a[0]? Is this something that
>>> will throw or not?
>>
>> Personally, I think that it should, but there's probably a good chance that it
>> won't, because it's an lvalue. I don't know what will happen with that though.
>> There are a lot of bugs right now related elements being inserted into AAs
>> when they shouldn't be, so I really don't know how much relation the current
>> behavior will have with the behavior that AAs will ultimately have.
>
> ++a[0] should work.

OK. But then let's also try to solve these standing issues:
Given a T[int], where T defines op++:

1. a[0] must be initialized to T.init first (and not memory zero'd, especially if T is user defined).
2. a must not be modified if T.op++ throws an exception.

Q. Is this specific to *operators* that mutate? What about normal function?:
  a[0].mutate();
    Q.1) create a T.init and call mutate on it?
    Q.2) Throw an exception

>>> As well, what about
>>> //----
>>> immutable(int)[int] aa;
>>> aa[0] = 5;
>>> //----
>>> This should work, right?
>>
>> That should definitely work. That's how you add elements to AA. My gripe with
>> something like ++a[0] working when there's no a[0] is that you'd be adding to
>> an element that doesn't exist yet.
>
> Shouldn't work.
>
> Andrei

I can see the problem: What if the key is already there?

However, I think this is just a limitation of the syntax. If AA's had an "insert" function that only inserts when the key doesn't exist (akin to C++'s set::insert), then we'd be able to have our AA's of immutables.

On Saturday, 12 January 2013 at 22:44:19 UTC, monarch_dodra wrote:
> Q. Is this specific to *operators* that mutate? What about normal function?:
>   a[0].mutate();
>     Q.1) create a T.init and call mutate on it?
>     Q.2) Throw an exception

I can answer that actually: It *must* throw an exception, because the implementation would have a hook for "opIndexFunction", so it would call "opIndex" + "Function", which would throw.

I'm not thrilled at the difference of behavior, but I guess we can make an exception and support "lazy insertion" for numeric operations.

On Saturday, 12 January 2013 at 21:56:13 UTC, Andrei Alexandrescu wrote:
> On 1/12/13 7:40 AM, Jonathan M Davis wrote:
>> On Saturday, January 12, 2013 13:30:47 monarch_dodra wrote:
>>> What about "++a[0]" when there is no a[0]? Is this something that
>>> will throw or not?
>>
>> Personally, I think that it should, but there's probably a good chance that it
>> won't, because it's an lvalue. I don't know what will happen with that though.
>> There are a lot of bugs right now related elements being inserted into AAs
>> when they shouldn't be, so I really don't know how much relation the current
>> behavior will have with the behavior that AAs will ultimately have.
>
> ++a[0] should work.
>

Can you explain why ?

On Saturday, January 12, 2013 16:56:13 Andrei Alexandrescu wrote:
> >> As well, what about
> >> //----
> >> immutable(int)[int] aa;
> >> aa[0] = 5;
> >> //----
> >> This should work, right?
> > 
> > That should definitely work. That's how you add elements to AA. My gripe with something like ++a[0] working when there's no a[0] is that you'd be adding to an element that doesn't exist yet.
> 
> Shouldn't work.

Yeah, you're right. I didn't think through that one enough. Why inserting immutable elements would work ideally, there's no difference between inserting and assigning as far as the operatiors used or functions called go, so we're forced to disallow insertion as well as assignment. So, assuming that the functions for querying the AA are const, there's not much difference between an AA of immutable elements and an immutable AA.

- Jonathan M Davis

On 1/12/13 8:26 PM, deadalnix wrote:
> On Saturday, 12 January 2013 at 21:56:13 UTC, Andrei Alexandrescu wrote:
>> On 1/12/13 7:40 AM, Jonathan M Davis wrote:
>>> On Saturday, January 12, 2013 13:30:47 monarch_dodra wrote:
>>>> What about "++a[0]" when there is no a[0]? Is this something that
>>>> will throw or not?
>>>
>>> Personally, I think that it should, but there's probably a good
>>> chance that it
>>> won't, because it's an lvalue. I don't know what will happen with
>>> that though.
>>> There are a lot of bugs right now related elements being inserted
>>> into AAs
>>> when they shouldn't be, so I really don't know how much relation the
>>> current
>>> behavior will have with the behavior that AAs will ultimately have.
>>
>> ++a[0] should work.
>>
>
> Can you explain why ?

Did so in https://github.com/D-Programming-Language/dmd/pull/1465

Andrei