On 2011-06-21 08:38:05 -0400, "Steven Schveighoffer"
<[email protected]> said:
On Tue, 21 Jun 2011 08:25:40 -0400, Michel Fortin
<[email protected]> wrote:
While there is no doubt that 'moving' a struct can often be used as an
optimization without changing the semantics, if you want the @disabled
attribute to be useful on the postblit constructor then the language
needs to define when its semantics require 'moving' data and whey then
require 'copying' data, it can't let that only to the choice of the
optimizer.
Another issue with appending a @disabled-postblit struct, what happens
when you have to reallocate a block to get more space? This cannot
possibly be a move, because the compiler has no idea at the time of
appending whether anything else has a reference to the original data.
So should it just be a runtime error?
That's indeed a problem.
I'm starting to think that @disabled postblit structs *shouldn't* be
able to be appended.
That would make sense. It should be a compile-time error.
It would also turn appending using move to an optimization, because all
the types you can append will be guarantied to be copyable.
--
Michel Fortin
[email protected]
http://michelf.com/
