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 reply "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
parent reply "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
parent reply "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
parent reply "Namespace" <rswhite4 googlemail.com> writes:
I thought that "new A()" could be implicit immutable. Thanks for 
reporting.
Sep 17 2012
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
prev 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