www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 7191] New: ctor/opAssign doesn't play nice with field initialization

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

           Summary: ctor/opAssign doesn't play nice with field
                    initialization
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: andrej.mitrovich gmail.com



09:50:39 PST ---
struct PointF {
    float x, y;
}

struct Point { 
    int x, y;
    this(PointF) { }
    void opAssign(PointF) { }    
}

struct Line {
    Point pt1;
    Point pt2;
}

void main() {
    Line line;
    line.pt1 = PointF(0, 0);  // ok
    line.pt2 = PointF(0, 0);  // ok

    auto line2 = Line(PointF(0, 0), PointF(0, 0));  // ng
}

I see no reason why field initialization shouldn't work if each field defines a
ctor or opAssign that can take such a type.

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




14:40:33 PDT ---
Simpler example:

-----
struct A
{
    this(B) { }
}

struct B
{
}

struct C
{
    A a;
}

void main()
{
    // field initialization, c.a = B(), 'a' defines ctor for 'B'
    auto c = C(B());  // error
}
-----

I'm not sure whether or not we want to support this. Should field
initialization allow implicit calls to a ctor of that field?

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


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc






 I'm not sure whether or not we want to support this. Should field
 initialization allow implicit calls to a ctor of that field?


I am not sure, but I think the current behavour is acceptable. If you want a
different behavour in Line you can add a ctor to it.

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


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement



15:47:28 PDT ---



 

 I'm not sure whether or not we want to support this. Should field
 initialization allow implicit calls to a ctor of that field?


 
 I am not sure, but I think the current behavour is acceptable. If you want a
 different behavour in Line you can add a ctor to it.


The OP code was an attempt at providing convenience functionality, but when I
think about this now almost 2 years later, this just complicates the API. This
is not a feature I desperately need.

I'm marking this an enhancement though.

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