Bug 7191 – ctor/opAssign doesn't play nice with field initialization

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.

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?

(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.

(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.

Yeah I fear this might have unexpected complications if the enhancement was implemented, and there wouldn't be that much benefit here. I'm closing this down.