www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6253] New: Refuse definition too of impossible associative arrays

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6253

           Summary: Refuse definition too of impossible associative arrays
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: accepts-invalid
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: bearophile_hugs eml.cc



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;

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 05 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6253




Two other persons agree:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=31374

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 03 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6253


Stewart Gordon <smjg iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com




 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[])] ---------- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 07 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6253




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.
-- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6253


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies gmail.com



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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6253


hsteoh quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh quickfur.ath.cx




 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? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6253






 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6253






 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 20 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6253




One more comment:

http://forum.dlang.org/thread/mailman.1834.1334688099.4860.digitalmars-d puremagic.com#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++.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 17 2012