Thread overview | ||||||
---|---|---|---|---|---|---|
|
December 31, 2011 [Issue 7191] New: ctor/opAssign doesn't play nice with field initialization | ||||
---|---|---|---|---|
| ||||
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 --- Comment #0 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-12-31 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: ------- |
September 17, 2013 [Issue 7191] ctor/opAssign doesn't play nice with field initialization | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | http://d.puremagic.com/issues/show_bug.cgi?id=7191 --- Comment #1 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-09-17 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: ------- |
September 17, 2013 [Issue 7191] ctor/opAssign doesn't play nice with field initialization | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | http://d.puremagic.com/issues/show_bug.cgi?id=7191 bearophile_hugs@eml.cc changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bearophile_hugs@eml.cc --- Comment #2 from bearophile_hugs@eml.cc 2013-09-17 15:44:32 PDT --- (In reply to comment #1) > 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: ------- |
September 17, 2013 [Issue 7191] ctor/opAssign doesn't play nice with field initialization | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | http://d.puremagic.com/issues/show_bug.cgi?id=7191 Andrej Mitrovic <andrej.mitrovich@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement --- Comment #3 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-09-17 15:47:28 PDT --- (In reply to comment #2) > (In reply to comment #1) > > > 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: ------- |
Copyright © 1999-2021 by the D Language Foundation