On Mon, 12 Sep 2011 17:36:09 -0400, Michel Fortin
<[email protected]> wrote:
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();
}
That is a brand new feature that was added after clear was implemented,
and I'm not sure of the semantics yet. I'd suspect that clear probably
should be statically disallowed if no default ctor is allowed.
If what Andrei says is true, however, then assigning to .init is still
feasible, and should be able to be destructed.
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 agree the name clear isn't ideal. I don't think we can change it now,
though.
But we need *something* that releases resources without reacquiring them.
The case for reinitializing resources after releasing them is pretty
uncommon. And in those cases, the object itself can support that, we
don't need a language solution.
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).
You can only reuse the object after if it's a struct. If it's an object,
you cannot. I think that's pretty much universal (does not depend on the
implementation of the struct/class).
I think the point of clear is, you are deallocating, and no longer using
that item. Using it afterwards is not supported without reinitialization.
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.
Clear is not meant to replace delete, clear + deallocate is.
The notion that the library provides a mechanism to do what clear does
*without* deallocation is a new concept. That concept extends very well
into non-heap-based types.
-Steve
