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 us
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.
I thought that "new A()" could be implicit immutable. Thanks for
reporting.
_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 ke
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 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 m
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;
