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?

Second, why  must an object in its entirety be copy-able for these functions to call toString() ?

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

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

On 3/22/19 9:24 AM, Alex wrote:
> On Friday, 22 March 2019 at 12:08:39 UTC, James Blachly wrote:
>> 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?).

Hi Alex,

Thanks for replying. I attribute the lack of sensibleness in my post to lack of sleep.

I actually am defining toString as member function of S, but it only now occurred to me that structs are always passed by value, not by reference. Of course then it cannot be copied.

Thanks again =)