On Thursday, 19 July 2018 at 10:04:34 UTC, RazvanN wrote:
I just don't understand why you would ever mark the destructor
of a struct with @disable. When is that useful? If it's not,
why not just forbit it?
struct S1 {
~this() { /* stuff */ }
}
struct S2 {
S1 s;
@disable ~this();
}
The idea would be that S1's destructor not be called when S2 goes
out of scope. Now, that's not how @disable works, but it's a
logical thought.
The way @disable does work though, isn't to remove the marked
function, but forbid it from being called.
why not make it illegal to disable the destructor if disabling
it will surely result in errors wherever the struct is used.
Because the error message when you use it clearly states what's
wrong?
It's actually possible to use a struct with a @disabled
destructor:
struct S {
int i;
@disable ~this() {}
}
struct Nodestruct(T) {
ubyte[T.sizeof] _payload;
@property
ref T value() {
return *cast(T*)_payload.ptr;
}
}
The trick is, as you can see, to never have an instance on the
stack. This gives a small advantage over @disable this(this) and
@disable this() in that it's actually impossible to have a
stack-allocated instance.
--
Simen
