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


--- Comment #0 from monarchdodra@gmail.com 2013-10-22 09:40:30 PDT ---
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: -------

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


--- Comment #1 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-10-22 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11325



--- Comment #2 from monarchdodra@gmail.com 2013-10-22 09:57:00 PDT ---
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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11325



--- Comment #3 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-10-22 12:44:21 PDT ---
(In reply to comment #2)
> 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11325


monarchdodra@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


--- Comment #4 from monarchdodra@gmail.com 2013-10-22 23:28:05 PDT ---
The call is now rejected.

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