www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11325] New: swap accepts aggregates with non-mutable fields

reply d-bugmail puremagic.com writes:
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
next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling parent d-bugmail puremagic.com writes:
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