www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11202] New: Copy constructor is called instead of assignment on member

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

           Summary: Copy constructor is called instead of assignment on
                    member
           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: verylonglogin.reg gmail.com


--- Comment #0 from Denis Shelomovskij <verylonglogin.reg gmail.com> 2013-10-09
11:13:52 MSD ---
---
struct S
{
    this(this) {}
     disable void opAssign(S);
}

struct T
{ S s; }

void main()
{
    S s1, s2;
    static assert(!__traits(compiles, s1 = s2));
    T t1, t2;
    static assert(!__traits(compiles, t1.tupleof = t2.tupleof));
    static assert(!__traits(compiles, t1 = t2)); // assert fails
}
---

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 09 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11202


monarchdodra gmail.com changed:

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


--- Comment #1 from monarchdodra gmail.com 2013-10-09 00:52:12 PDT ---
Hum... the issue is that T simply doesn't care about S's opAssign: It generates
its own opAssign via "postblit-copy-move" (of all of T at once I mean).

This isn't strictly *wrong*, its just a pretty dirty way of doing things, and
I'm pretty sure it's inefficient, and it definitly defeats the purpose of
having an opAssign to begin with.

It *is* the only way to provide *strong* exception guarantees though, for a
compiler generated elaborate opAssign, in case one of the member's opAssign
throws. *Should* we guarantee strong exception safety though? I'm unsure.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 09 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11202



--- Comment #2 from github-bugzilla puremagic.com 2013-10-09 07:05:00 PDT ---
Commit pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/c930d8bd5e5246653a0300aac791b4c82b0466c5
[Workaround] Disable some tests because of Issue 11202.

Issue URL: http://d.puremagic.com/issues/show_bug.cgi?id=11202

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 09 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11202


monarchdodra gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |samukha voliacable.com


--- Comment #3 from monarchdodra gmail.com 2013-10-15 06:03:31 PDT ---
*** Issue 11272 has been marked as a duplicate of this issue. ***

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