On 2011-09-12 20:04:05 +0000, "Steven Schveighoffer"
<[email protected]> said:
How does an author of a struct "not expect" the destructor to be called on
an .init version of itself? Isn't that an error? Do you have a
counter-case?
struct S
{
@disable this();
}
I hated having clear call the default constructor.
… because you use 'clear' to release resources. Which makes sense, but
goes contrary to expectations for something called 'clear'. What I am
saying is that 'clear' shouldn't be used to release resources,
something else should be used for that.
I think that's
entirely the wrong thing to do. clear + deallocate replaces delete, wit h
clear being the finalization of the data.
Well, if you really wanted clear + deallocate to replace delete
(regardless of the suitability of the name), don't make it so it looks
like you can reuse the object/struct afterward. Saying it is assigning
the 'init' state makes people believe the object will still be in a
usable state although actually there is no guaranty of that, and that's
true for a struct too (as shown above).
Also, if 'clear' is meant to replace 'delete', it should give an error
when called on non-GC memory because there's no way you can prevent the
destructor from being called a second time otherwise.
--
Michel Fortin
[email protected]
http://michelf.com/
