Disabling struct destructor illegal?

[Jim Balter]

On Thursday, 19 July 2018 at 10:04:34 UTC, RazvanN wrote:
> On Thursday, 19 July 2018 at 09:50:32 UTC, Jim Balter wrote:
>> On Thursday, 19 July 2018 at 08:50:15 UTC, RazvanN wrote:
>>> struct A
>>> {
>>>     int a;
>>>     @disable ~this() {}
>>> }
>>>
>>> void main()
>>> {
>>>     A a = A(2);
>>> }
>>>
>>> Currently, this code yields:
>>>
>>> Error: destructor `A.~this` cannot be used because it is 
>>> annotated with @disable
>>>
>>> I was expecting that disabling the destructor would make it 
>>> as if the struct does not have a destructor
>>
>> Why? That's not the semantics of @disable. And why would you 
>> want that? What are you actually trying to achieve?
>
> I just don't understand why you would ever mark the destructor 
> of a struct with @disable. When is that useful?

I don't know, but that doesn't mean there's no possible reason to.

> If it's not,

We haven't established that it's never useful. When you pose a 
conditional like that, it's a logical mistake to just assume that 
the condition is met.

> why not just forbit it?

Because the compiler shouldn't be littered with pointless special 
case restrictions that have to be maintained and might interfere 
with a valid use case that you haven't thought of. The fact is 
that you disabled the destructor, then invoked the destructor, 
and got a clear, informative error at the point of invocation, 
rather than at the @disable. This is, IMO, a cleaner, better 
design than the one you're asking for.

And it's not true that you "just" don't understand why one would 
ever @disable the destructor ... in your original post you asked 
"why not make it illegal to disable the destructor if disabling 
it will surely result in errors wherever the struct is used" -- 
it was pointed out that it *doesn't* "surely result in errors 
wherever the struct is used" -- it only results in an error if 
the destructor is invoked, exactly as one would expect. In your 
original post you claimed "The only situation where the code will 
compile is A is never used directly" -- it was pointed out that 
this isn't true, as your own example showed. In your original 
post you said that it was confusing that code that you had just 
erroneously stated wouldn't compile does compile, and it was 
pointed out that there's no reason why it shouldn't compile and 
there's no apparent reason to find it confusing. In your original 
post you asked if that's a bug, and it has been pointed out that 
it's not a bug. I hope everything is clear now and all your 
questions have been answered.