Comment #0 by bearophile_hugs — 2011-07-05T10:39:31Z
This program:
void main() {
bool[int[]] aa;
aa[[1, 2]] = true; // line 3
}
With DMD 2.053 gives a compile time-error:
test.d(3): Error: associative arrays can only be assigned values with immutable keys, not int[]
While this program works:
import std.stdio;
void main() {
bool[int[]] aa;
aa[[1, 2].idup] = true;
foreach (k, v; aa)
writeln(typeid(typeof(k)), " ", typeid(typeof(v)));
}
With DMD 2.053 it prints:
const(int)[] bool
So the writeln shows that that the keys of the associative array aa are mutable dynamic arrays of immutable integers. While the first program shows that the compiler refuses to add a mutable dynamic array as key.
I think this is bad, and not intuitive. I suggest to make DMD refuse this definition too:
bool[int[]] aa;
And accept this, and similar:
bool[const(int)[]] aa;
Comment #1 by bearophile_hugs — 2012-01-03T14:19:45Z
> (In reply to comment #0)
> This program:
>
> void main() {
> bool[int[]] aa;
> aa[[1, 2]] = true; // line 3
> }
>
> With DMD 2.053 gives a compile time-error:
> test.d(3): Error: associative arrays can only be assigned values
> with immutable keys, not int[]
If all the elements of an array literal bind to immutable types, then
so ought to whole array literal.
> I think this is bad, and not intuitive. I suggest to make DMD
> refuse this definition too:
> bool[int[]] aa;
Agreed.
> And accept this, and similar:
> bool[const(int)[]] aa;
Which should actually declare aa to be a bool[immutable(int)[]],
given that that's the only thing it will allow you to put in.
BTW the current behaviour (DMD 2.056) is actually rather weird:
----------
pragma(msg, (bool[int[]]).stringof);
pragma(msg, (bool[const(int)[]]).stringof);
pragma(msg, (bool[immutable(int)[]]).stringof);
pragma(msg, (bool[const(int[])]).stringof);
pragma(msg, (bool[immutable(int[])]).stringof);
----------
C:\Users\Stewart\Documents\Programming\D\d2\tests>dmd -c aa_array_param_type.d
bool[const(int)[]]
bool[const(int)[]]
bool[immutable(int)[]]
bool[const(int)[]]
bool[immutable(int[])]
----------
Comment #3 by bearophile_hugs — 2012-02-18T05:11:07Z
A partially contrary point of view by Ben Davis:
> Static arrays have value semantics, so char[4] is no more mutable than
> int would be. So if I'm required to write
>
> Chunk[immutable(char[4])]
>
> then I should also be required to write
>
> Chunk[immutable(int)]
>
> which clearly isn't the case.
Comment #4 by yebblies — 2012-02-18T05:27:56Z
AA keys don't have to be immutable, they just have to be a type that implicitly converts to immutable. This is the same requirement for parameters of strongly pure functions.
Comment #5 by hsteoh — 2012-03-19T20:45:56Z
Does (In reply to comment #4)
> AA keys don't have to be immutable, they just have to be a type that implicitly
> converts to immutable. This is the same requirement for parameters of strongly
> pure functions.
Does this mean AA keys should be stored as immutable internally?
Comment #6 by yebblies — 2012-03-19T22:48:54Z
(In reply to comment #5)
> Does (In reply to comment #4)
> > AA keys don't have to be immutable, they just have to be a type that implicitly
> > converts to immutable. This is the same requirement for parameters of strongly
> > pure functions.
>
> Does this mean AA keys should be stored as immutable internally?
I'd say yes, tail-immutable.
Comment #7 by smjg — 2012-03-20T15:45:53Z
(In reply to comment #5)
> Does (In reply to comment #4)
>> AA keys don't have to be immutable, they just have to be a type
>> that implicitly converts to immutable. This is the same
>> requirement for parameters of strongly pure functions.
>
> Does this mean AA keys should be stored as immutable internally?
Yes. A given key in the AA should never change on any level. Having the key type fully immutable (even if declared merely as tail-immutable) would enable it to be passed around by reference as immutable.
Comment #8 by bearophile_hugs — 2012-04-17T13:35:45Z
One more comment:
http://forum.dlang.org/thread/[email protected]#post-wnepqlefxamfbhddpaqs:40forum.dlang.org
This bug report is based on this idea:
http://en.wikipedia.org/wiki/Principle_of_least_astonishment
If I define:
Foo[] a;
I expect those Foo items to be mutable.
If I see:
int[Foo]
I expect those Foo keys to be mutable.
If I see:
immutable(Foo)[] a;
I expect those Foos to be immutable.
If I see:
int[immutable Foo]
I expect those Foo keys to be immutable.
If I see a int[Foo] and I get immutable Foo keys, I am astonished.
Not doing what I am saying here will add another special case to D language. Avoiding many special cases is a reasons to choose D over C++.
Comment #9 by robert.schadek — 2024-12-13T17:55:42Z