www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - More magical AA semantics

reply "Don" <don nospam.com> writes:
Consider this code:
---
    int[int] x;

    int k = x[2] + 5; // Error, range violation. Makes sense.

    x[2] = x[2] + 5;  // But this works!!!
---

That is, x[2] doesn't exist, *unless you are about to assign to
it*.

What happens is:
1. lvalue index (creates x[2], sets it to int.init)
2. rvalue index (returns x[2], which is now 0)
3. lvalue index assign (sets x[2] = 5)

In reality, step 1 returns a pointer to the newly created element.

How could this be implemented as a library type?
The superficially similar case, x[2] += 5; can be implemented
with opIndexOpAssign. But I don't know how to do this one.

Note that elements are not always magically created when an
lvalue is required. AFAIK it only happens in assignment. For
example this code gives a runtime error:
---
void foo(ref int g) { ++g; }

    int[int] x;
    foo( x[2] );  // range error, x[2] doesn't exist yet
---
Jan 10 2013
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 11, 2013 08:53:44 Don wrote:
 Consider this code:
 ---
     int[int] x;
 
     int k = x[2] + 5; // Error, range violation. Makes sense.
 
     x[2] = x[2] + 5;  // But this works!!!
 ---
 
 That is, x[2] doesn't exist, *unless you are about to assign to
 it*.
 
 What happens is:
 1. lvalue index (creates x[2], sets it to int.init)
 2. rvalue index (returns x[2], which is now 0)
 3. lvalue index assign (sets x[2] = 5)
 
 In reality, step 1 returns a pointer to the newly created element.
 
 How could this be implemented as a library type?
 The superficially similar case, x[2] += 5; can be implemented
 with opIndexOpAssign. But I don't know how to do this one.
 
 Note that elements are not always magically created when an
 lvalue is required. AFAIK it only happens in assignment. For
 example this code gives a runtime error:
 ---
 void foo(ref int g) { ++g; }
 
     int[int] x;
     foo( x[2] );  // range error, x[2] doesn't exist yet
 ---

I would argue that the fact that x[2] = x[2] + 5; works is a bug. Given some of the weirdness that happens with assigning to AA elements, it doesn't entirely surprise me. For instance, x[2] = funcThatThrows(); results in x[2] holding the init value of x's element type. But I think that it's indicative of problems with the current AA implementation which need to be fixed and not something that we should be trying to emulate with library types. - Jonathan M Davis
Jan 11 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 12 2013
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Friday, 11 January 2013 at 08:26:54 UTC, Jonathan M Davis 
wrote:
 On Friday, January 11, 2013 08:53:44 Don wrote:
 Consider this code:
 ---
     int[int] x;
 
     int k = x[2] + 5; // Error, range violation. Makes sense.
 
     x[2] = x[2] + 5;  // But this works!!!
 ---
 
 That is, x[2] doesn't exist, *unless you are about to assign to
 it*.
 
 What happens is:
 1. lvalue index (creates x[2], sets it to int.init)
 2. rvalue index (returns x[2], which is now 0)
 3. lvalue index assign (sets x[2] = 5)
 
 In reality, step 1 returns a pointer to the newly created 
 element.
 
 How could this be implemented as a library type?
 The superficially similar case, x[2] += 5; can be implemented
 with opIndexOpAssign. But I don't know how to do this one.
 
 Note that elements are not always magically created when an
 lvalue is required. AFAIK it only happens in assignment. For
 example this code gives a runtime error:
 ---
 void foo(ref int g) { ++g; }
 
     int[int] x;
     foo( x[2] );  // range error, x[2] doesn't exist yet
 ---

I would argue that the fact that x[2] = x[2] + 5; works is a bug.

I completely agree. Doesn't the spec say that relying on the order of assignment evaluation is undefined?
Jan 11 2013
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Don wrote:
 Consider this code:
 ---
    int[int] x;
 
    int k = x[2] + 5; // Error, range violation. Makes sense.
 
    x[2] = x[2] + 5;  // But this works!!!
 ---

I think the last statement is illegal. Because from http://dlang.org/expression.html I extract: The evaluation order of = is implementation defined and it is illegal to depend on it. The compiler should catch these but it cannot in all cases. If the evaluation order was fixed i.e. right-to-left in this case, the code would throw. It also happens that the evaluation may change depending on the optimization flags. So I believe it's an issue of evaluation order. Jens
Jan 11 2013
prev sibling next sibling parent "Don" <don nospam.com> writes:
On Friday, 11 January 2013 at 08:26:54 UTC, Jonathan M Davis 
wrote:
 On Friday, January 11, 2013 08:53:44 Don wrote:
 Consider this code:
 ---
     int[int] x;
 
     int k = x[2] + 5; // Error, range violation. Makes sense.
 
     x[2] = x[2] + 5;  // But this works!!!
 ---
 
 That is, x[2] doesn't exist, *unless you are about to assign to
 it*.


 How could this be implemented as a library type?


 I would argue that the fact that

 x[2] = x[2] + 5;

 works is a bug. Given some of the weirdness that happens with 
 assigning to AA
 elements, it doesn't entirely surprise me. For instance,

 x[2] = funcThatThrows();

 results in x[2] holding the init value of x's element type. But 
 I think that
 it's indicative of problems with the current AA implementation 
 which need to
 be fixed and not something that we should be trying to emulate 
 with library
 types.

That's my feeling too. I think that if we want to implement AAs as a library type, we first need to eliminate all of the semantics would be impossible to implement in a library. Specificially, I think we need to disallow semantics which are inconsistent with: struct AA { AAImpl impl; ref Value opIndex(Key key); Value opIndexAssign(Value value, Key key); Value opIndexOpAssign(string op)(Value value, Key key); } where the last two create the entry if it doesn't already exist. Those last two should also create a blank AA if it doesn't already exist. Personally I'd be much happier if instead, the blank AA was created at construction, so that AAs would be pure reference types, but at least the semantics are implementable.
Jan 11 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
See also:

http://d.puremagic.com/issues/show_bug.cgi?id=3825

Bye,
bearophile
Jan 11 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 11, 2013 10:03:54 Don wrote:
 That's my feeling too. I think that if we want to implement AAs
 as a library type, we first need to eliminate all of the
 semantics would be impossible to implement in a library.

Well, the AAs are _already_ a library type. That's a large part of why they have so many bugs. The transition to a library type was badly done, and we sorely need a new implementation. Also, because the compiler is generating hooks that druntime plugs into, the built-in AAs aren't restricted to quite the same semantics that a user-defined AA type would be, even though the AAs are implemented in druntime instead of the compiler. So, AFAIK, we don't really have a problem with the built-in AAs doing stuff that a library type can't do (that's not even possible at this point, because they're implemented with a library type). Rather, what we need is a new, properly templated solution. But that's a lot of work, and I believe that the last person who attempted it gave up on it beacuse of all the problems that he was running into. - Jonathan M Davis
Jan 11 2013
prev sibling next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Don" <don nospam.com> wrote in message 
news:imqicbgjotdtzfgwdeor forum.dlang.org...
 Consider this code:
 ---
    int[int] x;

    int k = x[2] + 5; // Error, range violation. Makes sense.

    x[2] = x[2] + 5;  // But this works!!!
 ---

Definitely a bug.
Jan 11 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
Shouldn't the rhs be evaluated before the lhs? Why would it be 
undefined/unspecified/etc.?
Jan 11 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 11 January 2013 at 08:55:55 UTC, Bernard Helyer wrote:
 I completely agree. Doesn't the spec say that relying on
 the order of assignment evaluation is undefined?

After a long discussion with Andrei, it seems that it is left to right.
Jan 11 2013
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
deadalnix wrote:
 On Friday, 11 January 2013 at 08:55:55 UTC, Bernard Helyer wrote:
I completely agree. Doesn't the spec say that relying on
the order of assignment evaluation is undefined?

After a long discussion with Andrei, it seems that it is left to right.

Then the spec should be fixed. unittest { int a = 0; ++a = a; assert(a == 1); } Don't know though whether you find it surprising that the above code passes? But whether it is left to right or right to left does not matter that much. At least it's defined and you can internalize it. The more I think about the more sense it makes to have it left to right. Jens
Jan 11 2013
prev sibling next sibling parent "Don" <don nospam.com> writes:
On Friday, 11 January 2013 at 09:20:13 UTC, Jonathan M Davis 
wrote:
 On Friday, January 11, 2013 10:03:54 Don wrote:
 That's my feeling too. I think that if we want to implement AAs
 as a library type, we first need to eliminate all of the
 semantics would be impossible to implement in a library.

Well, the AAs are _already_ a library type. That's a large part of why they have so many bugs. The transition to a library type was badly done, and we sorely need a new implementation. Also, because the compiler is generating hooks that druntime plugs into, the built-in AAs aren't restricted to quite the same semantics that a user-defined AA type would be, even though the AAs are implemented in druntime instead of the compiler.

Unfortunately, that's not true. All that happened was that a template layer was added on top of the built-in implementation. The compiler still knows intimate details about the implementation. The number of hooks from the compiler to the runtime have not decreased; in fact, they have increased. AFAIK there is not a single place in the compiler where coupling between compiler and runtime decreased. There are very many places where it got much more complicated.
 So, AFAIK, we don't really have a problem with the built-in AAs 
 doing stuff
 that a library type can't do (that's not even possible at this 
 point, because
 they're implemented with a library type).

It's not a library type in a meaningful sense. The semantics come almost entirely from the compiler, not from the library. There's almost nothing in the implementation that can be changed without changing the compiler.
Jan 11 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 11 January 2013 at 10:16:28 UTC, Jens Mueller wrote:
 deadalnix wrote:
 On Friday, 11 January 2013 at 08:55:55 UTC, Bernard Helyer 
 wrote:
I completely agree. Doesn't the spec say that relying on
the order of assignment evaluation is undefined?

After a long discussion with Andrei, it seems that it is left to right.

Then the spec should be fixed. unittest { int a = 0; ++a = a; assert(a == 1); }

++a isn't supposed to be an lvalue (it is not assignable).
 Don't know though whether you find it surprising that the above 
 code
 passes? But whether it is left to right or right to left does 
 not matter
 that much. At least it's defined and you can internalize it.
 The more I think about the more sense it makes to have it left 
 to right.

It shouldn't pass as the entry has never been assigned when computing the value.
Jan 11 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--f46d04016c2d2d7f4a04d3005fc2
Content-Type: text/plain; charset=UTF-8

aa[key] = val;

should be evaluated:

1. aa
2. key
3. val
4. aa[key] = val <-- allocating slot and set to it

Kenji Hara
2013/01/11 18:56 "deadalnix" <deadalnix gmail.com>:

 On Friday, 11 January 2013 at 08:55:55 UTC, Bernard Helyer wrote:

 I completely agree. Doesn't the spec say that relying on
 the order of assignment evaluation is undefined?

After a long discussion with Andrei, it seems that it is left to right.

--f46d04016c2d2d7f4a04d3005fc2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p>aa[key] =3D val;</p> <p>should be evaluated:</p> <p>1. aa<br> 2. key<br> 3. val<br> 4. aa[key] =3D val &lt;-- allocating slot and set to it</p> <p>Kenji Hara</p> <div class=3D"gmail_quote">2013/01/11 18:56 &quot;deadalnix&quot; &lt;<a hr= ef=3D"mailto:deadalnix gmail.com">deadalnix gmail.com</a>&gt;:<br type=3D"a= ttribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex"> On Friday, 11 January 2013 at 08:55:55 UTC, Bernard Helyer wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I completely agree. Doesn&#39;t the spec say that relying on<br> the order of assignment evaluation is undefined?<br> </blockquote> <br> After a long discussion with Andrei, it seems that it is left to right.<br> </blockquote></div> --f46d04016c2d2d7f4a04d3005fc2--
Jan 11 2013
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
deadalnix wrote:
 On Friday, 11 January 2013 at 10:16:28 UTC, Jens Mueller wrote:
deadalnix wrote:
On Friday, 11 January 2013 at 08:55:55 UTC, Bernard Helyer
wrote:
I completely agree. Doesn't the spec say that relying on
the order of assignment evaluation is undefined?

After a long discussion with Andrei, it seems that it is left to right.

Then the spec should be fixed. unittest { int a = 0; ++a = a; assert(a == 1); }

++a isn't supposed to be an lvalue (it is not assignable).

Really? I thought the semantics (of ++a) are increment a and return a reference to it. Whereas a++ is rewritten to (auto t = e, ++e, t). That means it returns a copy of the old value of a.
Don't know though whether you find it surprising that the above
code
passes? But whether it is left to right or right to left does not
matter
that much. At least it's defined and you can internalize it.
The more I think about the more sense it makes to have it left to
right.

It shouldn't pass as the entry has never been assigned when computing the value.

Isn't this a speciality of AAs in D/C++? When you access an non existing element it gets created? You do not need to assign to it. Jens
Jan 11 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 11 January 2013 at 10:43:33 UTC, Jens Mueller wrote:
 deadalnix wrote:
 On Friday, 11 January 2013 at 10:16:28 UTC, Jens Mueller wrote:
deadalnix wrote:
On Friday, 11 January 2013 at 08:55:55 UTC, Bernard Helyer
wrote:
I completely agree. Doesn't the spec say that relying on
the order of assignment evaluation is undefined?

After a long discussion with Andrei, it seems that it is left to right.

Then the spec should be fixed. unittest { int a = 0; ++a = a; assert(a == 1); }

++a isn't supposed to be an lvalue (it is not assignable).

Really? I thought the semantics (of ++a) are increment a and return a reference to it. Whereas a++ is rewritten to (auto t = e, ++e, t). That means it returns a copy of the old value of a.

It is meant to be an lvalue, and is the reason this is legal in both C++ and D: int main() { int a = 0; ++++a; return 0; }
Jan 11 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 11 January 2013 at 10:59:00 UTC, monarch_dodra wrote:
 It is meant to be an lvalue, and is the reason this is legal in 
 both C++ and D:

 int main()
 {
     int a = 0;
     ++++a;
     return 0;
 }

OK, it seems I talked too fast here. Still it seems very weird to me :D
Jan 11 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 11 January 2013 at 09:50:18 UTC, deadalnix wrote:
 On Friday, 11 January 2013 at 08:55:55 UTC, Bernard Helyer 
 wrote:
 I completely agree. Doesn't the spec say that relying on
 the order of assignment evaluation is undefined?

After a long discussion with Andrei, it seems that it is left to right.

This seems wrong to me. In particular, if you define an opIndexAssign, then the RHS *has* to be evaluated first (from a "visual" point of view, since LHS is pretty much "this"). //---- a[0] = a[0] //---- Becomes //---- a.opIndexAssign(a[0], 0); //---- On a related note, I don't know how AA's are actually implemented, but it sounds like giving them opIndexXXX would solve a lot of our problems: * Initialization to T.init if RHS throws * a[0] = a[0]; runs if there is no a[0]. Or even code such as this: //---- int[int] a; ++a[0]; //---- In what universe do we actually expect this to work? It shouldn't.
Jan 11 2013
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Don wrote:
 Consider this code:
 ---
    int[int] x;
 
    int k = x[2] + 5; // Error, range violation. Makes sense.
 
    x[2] = x[2] + 5;  // But this works!!!
 ---

 That is, x[2] doesn't exist, *unless you are about to assign to
 it*.
 What happens is:
 1. lvalue index (creates x[2], sets it to int.init)
 2. rvalue index (returns x[2], which is now 0)
 3. lvalue index assign (sets x[2] = 5)
 
 In reality, step 1 returns a pointer to the newly created element.
 
 How could this be implemented as a library type?
 The superficially similar case, x[2] += 5; can be implemented
 with opIndexOpAssign. But I don't know how to do this one.
 
 Note that elements are not always magically created when an
 lvalue is required. AFAIK it only happens in assignment. For
 example this code gives a runtime error:
 ---
 void foo(ref int g) { ++g; }
 
    int[int] x;
    foo( x[2] );  // range error, x[2] doesn't exist yet
 ---

I don't know how opIndex is defined and I cannot find appropriate documentation at http://dlang.org/hash-map.html. But you're right this is odd. Either opIndex throws a RangeError or it creates a value. I would probably go with the C++ approach: creating the value if it does not exist. I.e. making the second statement legal. Then k is int.init + 5. Sorry for my first post. I didn't see it clear. Jens
Jan 11 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 11 January 2013 at 11:14:27 UTC, monarch_dodra wrote:
 In particular, if you define an opIndexAssign, then the RHS 
 *has* to be evaluated first (from a "visual" point of view, 
 since LHS is pretty much "this").

 //----
 a[0] = a[0]
 //----
 Becomes
 //----
 a.opIndexAssign(a[0], 0);
 //----

It is probably not gonna change at this point, but opIndexAssign seems wrong here, not the LTR evaluation.
Jan 11 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 11 January 2013 at 13:27:46 UTC, deadalnix wrote:
 On Friday, 11 January 2013 at 11:14:27 UTC, monarch_dodra wrote:
 In particular, if you define an opIndexAssign, then the RHS 
 *has* to be evaluated first (from a "visual" point of view, 
 since LHS is pretty much "this").

 //----
 a[0] = a[0]
 //----
 Becomes
 //----
 a.opIndexAssign(a[0], 0);
 //----

It is probably not gonna change at this point, but opIndexAssign seems wrong here, not the LTR evaluation.

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]". I was wondering: if AA's are "library types", as we have been claiming they are, then *how* does //---- a[0] = a[0]; //---- Even work? The way I see it, there is 1 of 2 possible implementations: ==== 1 ==== Simple "ref T opIndex(size_t);" implementation: This does not allow distinguishing read from write, so would crash on *any* call to an empty field. ==== 2 ==== With opIndexAssign. But if we *did* have opIndexAssign, then we wouldn't have these problems, and the code such as "++a[0];" would correctly throw. So what gives? My guess is that the compiler only has opIndex, but cheats to know if it is a write: //---- immutable(int)[int] a; a[0] = 5; //---- Error: a[0] isn't mutable //---- That's a tell-tale sign the compiler is cheating on us. What's more, if AA used opIndexAssign, this assignment would actually work.
Jan 11 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
While we chat, the good Hara delivers :o)

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

Bye,
bearophile
Jan 11 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 11, 2013 at 08:53:44AM +0100, Don wrote:
 Consider this code:
 ---
    int[int] x;
 
    int k = x[2] + 5; // Error, range violation. Makes sense.
 
    x[2] = x[2] + 5;  // But this works!!!
 ---
 
 That is, x[2] doesn't exist, *unless you are about to assign to
 it*.

http://d.puremagic.com/issues/show_bug.cgi?id=3825
 What happens is:
 1. lvalue index (creates x[2], sets it to int.init)

Actually it doesn't. It binary-zeroes the entry.
 2. rvalue index (returns x[2], which is now 0)
 3. lvalue index assign (sets x[2] = 5)
 
 In reality, step 1 returns a pointer to the newly created element.

Yeah that's pretty much what's happening currently.
 How could this be implemented as a library type?

I'd argue that this behaviour is a bug, and *shouldn't* be implemented in the library type. This behaviour causes, for example, real[string] to have 0.0 as default entry value instead of nan, like the rest of the language.
 The superficially similar case, x[2] += 5; can be implemented
 with opIndexOpAssign. But I don't know how to do this one.

There's another problem: there is currently no operator overload that can handle things like a['b']['c']=d, because the first [] is a lookup and the second [] is an assignment.
 Note that elements are not always magically created when an
 lvalue is required. AFAIK it only happens in assignment. For
 example this code gives a runtime error:
 ---
 void foo(ref int g) { ++g; }
 
    int[int] x;
    foo( x[2] );  // range error, x[2] doesn't exist yet
 ---

I think this is correct behaviour. The previous case I consider a bug. T -- No! I'm not in denial!
Jan 11 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/11/2013 08:53 AM, Don wrote:
 Consider this code:
 ---
     int[int] x;

     int k = x[2] + 5; // Error, range violation. Makes sense.

     x[2] = x[2] + 5;  // But this works!!!
 ---

 That is, x[2] doesn't exist, *unless you are about to assign to
 it*.

 What happens is:
 1. lvalue index (creates x[2], sets it to int.init)
 2. rvalue index (returns x[2], which is now 0)
 3. lvalue index assign (sets x[2] = 5)

 In reality, step 1 returns a pointer to the newly created element.

 How could this be implemented as a library type?
 The superficially similar case, x[2] += 5; can be implemented
 with opIndexOpAssign. But I don't know how to do this one.

struct S{ private int[int] x; int opIndex(int k){ return x[k]; } void opIndexAssign(lazy int v, int k){ x[k]=v; } } void main(){ S x; int k = x[2] + 5; // Error x[2] = x[2] + 5; // Ok } =P
 Note that elements are not always magically created when an
 lvalue is required. AFAIK it only happens in assignment. For
 example this code gives a runtime error:
 ---
 void foo(ref int g) { ++g; }

     int[int] x;
     foo( x[2] );  // range error, x[2] doesn't exist yet
 ---

Now I'm lost too. Anyway, I do not consider the behaviour particularly useful.
Jan 11 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Jan 11 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
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.
Jan 12 2013
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, January 12, 2013 11:51:59 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 that should result in a RangeError. It's not something that's supposed to work. It's a bug. So, the fact that a library type couldn't duplicate it is irrelevant. The fact that it can't have a particular bug isn't exactly a problem. - Jonathan M Davis
Jan 12 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 12 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 12 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Saturday, 12 January 2013 at 12:05:30 UTC, Jonathan M Davis 
wrote:
 On Saturday, January 12, 2013 11:51:59 monarch_dodra wrote:
 
 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 that should result in a RangeError. It's not something that's supposed to work. It's a bug. So, the fact that a library type couldn't duplicate it is irrelevant. The fact that it can't have a particular bug isn't exactly a problem. - Jonathan M Davis

Oh... Right... I guess I missread this thread (and 9rnsr's pull), and was lead to understand that we were going the road of accepting this. Well, my bad than. What about "++a[0]" when there is no a[0]? Is this something that will throw or not? As well, what about //---- immutable(int)[int] aa; aa[0] = 5; //---- This should work, right?
Jan 12 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, January 12, 2013 13:30:47 monarch_dodra wrote:
 On Saturday, 12 January 2013 at 12:05:30 UTC, Jonathan M Davis
 
 wrote:
 On Saturday, January 12, 2013 11:51:59 monarch_dodra wrote:
 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 that should result in a RangeError. It's not something that's supposed to work. It's a bug. So, the fact that a library type couldn't duplicate it is irrelevant. The fact that it can't have a particular bug isn't exactly a problem. - Jonathan M Davis

Oh... Right... I guess I missread this thread (and 9rnsr's pull), and was lead to understand that we were going the road of accepting this. Well, my bad than.

I don't know what he's doing in his pull, but I think that it's clear that it should be a RangeError, and I don't think that much of anyone in this thread is disputing that.
 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.
 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. - Jonathan M Davis
Jan 12 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
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.
Jan 12 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jan 12 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
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 "++".
Jan 12 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Jan 12 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
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.
Jan 12 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
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.
Jan 12 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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 ?
Jan 12 2013
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jan 12 2013