Re: ref keys
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
Re: ref keys
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.
Re: ref keys
I thought that "new A()" could be implicit immutable. Thanks for reporting.
Re: 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
Re: ref keys
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.
Re: ref keys
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
ref keys
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
