On 2011-06-20 18:12:11 -0400, "Steven Schveighoffer"
<[email protected]> said:
On Mon, 20 Jun 2011 16:45:44 -0400, Michel Fortin
<[email protected]> wrote:
My feeling is that array appending and array assignment should be
considered a compiler issue first and foremost. The compiler needs to
be fixed, and once that's done the runtime will need to be updated
anyway to match the changes in the compiler. Your proposed fix for
array assignment is a good start for when the compiler will provide
the necessary info to the runtime, but applying it at this time will
just fix some cases by breaking a few others: net improvement zero.
BTW, I now feel that your request to make a distinction between move
and copy is not required. The compiler currently calls the destructor
of temporaries, so it should also call postblit. I don't think it can
make the distinction between array appending and simply calling some
other function.
Well, if
a ~= S();
does result in a temporary which get copied and then destroyed, why
have move semantics at all? Move semantics are not just an
optimization, they actually change the semantics. If you have a struct
with a @disabled postblit, should it still be appendable?
If the issue of array assignment is fixed, do you think it's worth
putting the change in, and then filing a bug against the GC? I still
think the current cases that "work" are fundamentally broken anyways.
That depends. I'm not too sure currently whether the S destructor is
called for this code:
a ~= S();
If the compiler currently calls the destructor on the temporary S
struct, then your patch is actually a fix because it balances
constructors and destructors correctly for the appending part (the bug
is then that compiler should use move semantics but is using copy
instead). If it doesn't call the destructor then your patch does
introduce a bug for this case.
All in all, I don't think it's important enough to justify we waste
hours debating in what order we should fix those bugs. Do what you
think is right. If it becomes a problem or it introduces a bug here or
there, we'll adjust, at worse that means a revert of your commit.
As for the issue that destructors aren't called for arrays on the heap,
it's a serious problem. But it's also a separate problem that concerns
purely the runtime, as far as I am aware of. Is there someone working
on it?
I think we need precise scanning to get a complete solution. Another
option is to increase the information the array runtime stores in the
memory block (currently it only stores the "used" length) and then hook
the GC to call the dtors. This might be a quick fix that doesn't
require precise scanning, but it also fixes the most common case of
allocating a single struct or an array of structs on the heap.
The GC calling the destructor doesn't require precise scanning.
Although it's true that both problems require adding type information
to memory blocks, beyond that requirement they're both independent.
It'd be really nice if struct destructors were called correctly.
--
Michel Fortin
[email protected]
http://michelf.com/
