So, postblits are considered a legacy construct that should be migrated to copy constructors. However, there is an instance where that cannot be done: --- struct PostBlitted(alias al){ this(this){} void x(){} //a member function so that an instance contains a frame pointer } struct CopyConstructed(alias al){ this(ref typeof(this)){}; void x(){} //a member function so that an instance contains a frame pointer } void main(){ PostBlitted!(x => x) a; CopyConstructed!(x => x) b; a.f; //compiles b.f; //does not } void f(T)(T x){ T y = x; } --- There should be a way to define a copy constructor so that it works even when the caller does not have a frame pointer for the new struct instance.
This affects normal constructors as well (copy constructors are just a particularization of a normal constructor): struct Normal(alias al) { this(int a) {} void x() {} } void main() { Normal!(x => x) a; a.f; } void f(T)(T x) { T y = 6; }
Hmmm, this code fails also: struct PostBlitted(alias al) { this(this){} void x(){} //a member function so that an instance contains a frame pointer } void main() { PostBlitted!(x => x) a; a.f; } void f(T)(T x) { T y; }
That last example is supposed to fail. `PostBlitted!(x => x)` contains a hidden context pointer to `main` to construct, so they can be default-initialized only at `main`. Not at `f`. (It could be argued that no frame pointer should be needed because `x => x` does not use any variables from `main`, but that's a different issue) Default blittings, and thus postblits, work, because the hidden context pointer gets copied from the original instance. But I can't come up with a way to do the same with a copy constructor. Well, I suppose I could devise a workaround with `static opCall`, but we're supposed to replace postblits with copy constructors, not with hackish workarounds.
*** Issue 22499 has been marked as a duplicate of this issue. ***
When trying to add a copy constructor to a type in an existing code base, I've been seeing a lot of errors about not having a frame pointer (particularly from std.algorithm code), which has been incredibly annoying to deal with, and it has made no sense to me that a frame pointer would even be needed, since the only difference is that a copy constructor has been added (though honestly, the whole frame pointer stuff is incredibly confusing in general). So, I'm _guessing_ that this is the issue that I've been hitting, but man, it would be nice if the compiler didn't decide that it needed a frame pointer that it can't have just because a type that's involved got a copy constructor added to it.
The reason for the frame pointer is: void test(int i) { struct S { int x; int f() { return x + i; } // reference to `i` } pragma(msg, S.sizeof); // prints 16 } so member functions can access variables in the function the struct is nested in. To avoid this, use `static`: void test(int i) { static struct S { int x; int f() { return x + i; } } pragma(msg, S.sizeof); // prints 4 } test2.d(7): Error: function `test2.test.S.f` cannot access variable `i` in frame of function `test2.test` test2.d(2): `i` declared here The compiler does a conservative guess as to whether a frame pointer is needed. A non-static member function will trip that. The compiler does not look at the body of the function to determine this, because the body may be defined elsewhere. The alias parameter also trips the "needs a frame pointer" for similar reasons. To resolve the problem, declare the template as `static`: static struct PostBlitted(alias al){ this(this){} void x(){} //a member function so that an instance contains a frame pointer } static struct CopyConstructed(alias al){ this(ref typeof(this)){}; void x(){} //a member function so that an instance contains a frame pointer } The fix for this bug should be to point this out in the spec.
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18053 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB