Ruling out arbitrary cost copy construction?

[dsimcha]

Vote++.  IMHO the problem with arbitrary cost copy construction is that
abstractions that are this leaky don't actually make people's lives simpler.
Abstractions (like value semantics) are supposed to make the code easier to reason
about.  When an abstraction forces you to think hard about things as trivial as
variable assignments, I think it's better to either scrap the abstraction and
require all copying to be explicit, or use a less leaky abstraction like reference
counting/COW.

With regard to using reference counting/COW instead of eager copying, I understand
the objection that seemingly innocent actions can throw.  However, I assume when
this has been mentioned in the past the exception in question was out of memory.
Few programs are actually designed to handle out of memory errors anyhow, except
maybe in a very generic way very far up the call stack.  That's why D declares out
of memory to be an Error instead of an Exception.  Therefore, this issue is IMHO a
non-issue.

To play Devil's Advocate a little, though, I do think we've substantially
mitigated the bloat issue by defining default behavior for moveFront() and friends
in cases where either there's no postblit or the range returns by reference.  This
way you only need to care about these functions if you're writing a sealed range
that you plan to put structs w/ postblits in.