digitalmars.D.bugs - [Issue 11325] New: swap accepts aggregates with non-mutable fields
- d-bugmail puremagic.com (30/30) Oct 22 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11325
- d-bugmail puremagic.com (23/23) Oct 22 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11325
- d-bugmail puremagic.com (23/23) Oct 22 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11325
- d-bugmail puremagic.com (7/9) Oct 22 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11325
- d-bugmail puremagic.com (11/11) Oct 22 2013 http://d.puremagic.com/issues/show_bug.cgi?id=11325
http://d.puremagic.com/issues/show_bug.cgi?id=11325 Summary: swap accepts aggregates with non-mutable fields Product: D Version: D2 Platform: All OS/Version: All Status: NEW Keywords: accepts-invalid Severity: normal Priority: P2 Component: Phobos AssignedTo: nobody puremagic.com ReportedBy: monarchdodra gmail.com Which basically means it mutates the immutable: unittest { struct S { const int i; } S s1 = S(0); S s2 = S(1); swap(s1, s2); //Clobbers i. } Swap being a trusted function, this is not acceptable. https://github.com/D-Programming-Language/phobos/pull/1603 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 22 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11325 Andrej Mitrovic <andrej.mitrovich gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrej.mitrovich gmail.com 09:48:03 PDT --- In git-head I can't reproduce your test-case: ----- import std.algorithm; void main() { struct S { const int i; } S s1 = S(0); S s2 = S(1); swap(s1, s2); // Error: cannot modify struct lhs S with immutable members } ----- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 22 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11325 Are you on the *latest* head? It was partially introduced with my latest non-assignable fix. However, it was also a pre-existing case (albeit harder to hit), if the type actually had an elaborate assign: //---- struct S { void opAssign(S){} const int i; } S s1 = S(0); S s2 = S(1); swap(s1, s2); //Clobbers i. //---- This "correctly" bypasses the opAssign, clobering i. The question is: do we want to cater to types that *have* an opAssign, but can't be memory *moved*? Tough question imo. Although I guess we could cater to that in a separate ER. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 22 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11325 12:44:21 PDT ---Are you on the *latest* head? It was partially introduced with my latest non-assignable fix.Ah, ok had a slightly outdated Phobos. I can reproduce now. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 22 2013
http://d.puremagic.com/issues/show_bug.cgi?id=11325 monarchdodra gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED The call is now rejected. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 22 2013