Member is @disable this(this), parent uncopyable

Alex sascha.orlov at gmail.com
Fri Mar 22 13:24:35 UTC 2019


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



More information about the Digitalmars-d-learn mailing list