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

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

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.

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

I thought that "new A()" could be implicit immutable. Thanks for reporting.

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.

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