On Friday, 22 March 2019 at 12:08:39 UTC, James Blachly wrote:
I have a struct S with member containers.UnrolledList [1].
UnrolledList is @disable this(this), but this unfortunately
makes my struct S also un-copyable, which now breaks some of my
debugging statements which rely on toString, as writeln,
format, etc. all copy the object. This leaves me in the
unfortunate situation that my release builds work, but debug
builds do not.
First, how do we deal with toString, std.format, writeln, etc.
with un-copyable objects, when it is only a member that is
uncopyable? In my case I got around this by creating a pointer
and moving the initialization to the constructor, but I wonder
if there are other ways?
You could (and should) define your custom toString() method
inside the struct S, where un-copyable (or other strange kinds)
members are part of.
In such a way, you could
S s;
s.toString(), without any harm, possibly omitting the members,
which you are sure of (such as UnrolledList?).
https://wiki.dlang.org/Defining_custom_print_format_specifiers
And, as a joke: Why are you debugging via printing and not by
writing asserts, heh? ;)
Second, why must an object in its entirety be copy-able for
these functions to call toString() ?
If you pass your struct S to toString of std, how should it know,
which members can be omitted? And well... S is copied because std
assumes, structures are cheap.
Finally, the error message gave no clue that it was a member
(UnrolledList in my case) that was @disable 'd and it took some
digging back through several commits to figure out what was
happening -- how could we improve the error messaging?
Thanks as always in advance
[1] https://github.com/dlang-community/containers
