www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - ref keys

reply "Namespace" <rswhite4 googlemail.com> writes:
Until now it is possible to have const keys in assocative arrays, 
e.g. Tile[const Vector2s], but it isn't possible to have ref 
keys, e.g. Tile[ref Vector2s].

If I have this code:
[code]
class A { }

A a1 = new A();
int[A] array;
[/code]

I can do:
array[new A()] = 42;
array[a1] = 23;

Both lines are valid.
But if I would access the elements later with their keys, I can't 
because I have not a valid key for the element 42, only for 23.

so my suggestion is: allow ref keys.

int[ref A] array;
array[new A()] = 42; // <-- error, new A() isn't a lvalue
array[a1] = 23; // <-- fine
Sep 17 2012
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, September 17, 2012 15:42:55 Namespace wrote:
 Until now it is possible to have const keys in assocative arrays,

Keys are supposed to be immutable. If that's not enforced by the compiler, then it's a bug. Given the current issues with the implementation for AAs' it wouldn't surprise me in the least if the compiler does not enforce this like it's supposed to, but regardless, that's the design. All AA keys must be immutable (or implicitly convertible to immutable) so that they can never change and screw up your AA. So, all AA key types are supposed to be inferred as immutable if they're not explicitly marked as such, and any time that an AA is accessed, the key used must either be immutable or implicitly convertible to immutable. And in the case of classes, that means that it must be outright immutable. - Jonathan M Davis
Sep 17 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
As you can see here, you can change the key very easily: 
http://dpaste.dzfl.pl/71697a23

But even they would be immutable: I have still no guarantee that 
my key must be a lvalue. Or am I wrong? Otherwise I'm still for 
ref keys.
Sep 17 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, September 17, 2012 20:56:21 Namespace wrote:
 As you can see here, you can change the key very easily:
 http://dpaste.dzfl.pl/71697a23

It's a bug. It should already be reported somewhere, but I can't find it, so re-reported it: http://d.puremagic.com/issues/show_bug.cgi?id=8681 The compiler properly checks for immutability with arrays but fails to with objects for some reason.
 But even they would be immutable: I have still no guarantee that
 my key must be a lvalue. Or am I wrong? Otherwise I'm still for
 ref keys.

Why would the key need to be an lvalue? You're _never_ supposed to assign to it or alter it in any way. If you do that (which the compiler is supposed to prevent), then that screws up the hashing. If you changed the value of a key, then when you went to fetch the element associated with it, you wouldn't find it, because the hash had changed. - Jonathan M Davis
Sep 17 2012
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
I thought that "new A()" could be implicit immutable. Thanks for 
reporting.
Sep 17 2012
prev sibling next sibling parent "anonymous" <anonymous example.com> writes:
On Monday, 17 September 2012 at 13:42:08 UTC, Namespace wrote:
 I can do:
 array[new A()] = 42;
 array[a1] = 23;

 Both lines are valid.
 But if I would access the elements later with their keys, I 
 can't because I have not a valid key for the element 42, only 
 for 23.

 so my suggestion is: allow ref keys.

 int[ref A] array;
 array[new A()] = 42; // <-- error, new A() isn't a lvalue
 array[a1] = 23; // <-- fine

What problem are you trying to solve here? When I forget to keep the key around, I'll notice that. I don't need lvalue keys for that.
Sep 17 2012
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, September 17, 2012 23:11:42 Namespace wrote:
 I thought that "new A()" could be implicit immutable. Thanks for
 reporting.

I'm sure that there are places where the compiler theoretically could implicitly convert a class or struct instantiated with new to immutable (e.g. when it's use to initialize an immutable variable), but it doesn't currently work that way. You have to explicitly construct it as immutable. Pretty much only built-in value types and structs which are value types can be implicitly converted to immutable (and in some cases, the result of a strongly pure function can be - at least with arrays). - Jonathan M Davis
Sep 17 2012