On Tuesday, 16 February 2021 at 09:04:43 UTC, Boris Carvajal
wrote:
I don't think this is intended rather it appears to be a
bug/deficiency in the constructor flow analysis of DMD, which
from what I'm reading is very rudimentary.
If I'm using a delegate in B, supplied to super() and called
On Sunday, 14 February 2021 at 08:46:34 UTC, frame wrote:
The first instance is in A - and why opAssign then works there?
Sorry I didn't pay too much attention.
It seems the detection of first assignment only happens when the
field and constructor have the same parent, so it doesn't work
On Sunday, 14 February 2021 at 08:38:49 UTC, Boris Carvajal wrote:
On Sunday, 14 February 2021 at 07:09:20 UTC, frame wrote:
Although x is well initialized by A by calling opAssign(), the
compiler doesn't care and calls the S!T ctor() on B again and
opAssign() is ignored. Is this a bug or a
On Sunday, 14 February 2021 at 07:09:20 UTC, frame wrote:
Although x is well initialized by A by calling opAssign(), the
compiler doesn't care and calls the S!T ctor() on B again and
opAssign() is ignored. Is this a bug or a rule?
It's a rule described here:
I have generic types that are initialized by a base class for
each derived object:
struct S(T) {
this(T val) {
value = 100;
}
void opAssign(T val) {
value = val;
}
T value;
}
class A {
this(this T)() {
foreach (property; __traits(allMembers,
