Ruling out arbitrary cost copy construction?

[Andrei Alexandrescu]

On 10/29/10 7:55 CDT, Bruno Medeiros wrote:
> On 06/10/2010 17:57, dsimcha wrote:
>> 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.
>
> I agree with this as well.
>
> But I'm still wondering if the original copy construction problem
> couldn't be solved in some other way.

FWIW this matter is still tormenting me. It gridlocks work on ranges, 
algorithms, and containers.

To recap:

1. Arbitrary cost copy construction:

+ Makes value types easy to define: just hook the copying code into 
this(this)
+ Is familiar to programmers coming from C++
+ If it fails, fails early, not surprisingly during a later operation
- Creates inefficiencies for innocuous-looking code
- Contorts code that wants to be efficient
- Makes containers, ranges and other abstractions bulkier and more 
difficult to define, implement, and use
- Forces exposure of raw addresses, which hurt abstraction power and safety

2. Constant-cost copy construction (via mandatory refcounting for value 
types):

+ Simplifies life virtually everywhere in client code
+ Makes code easy to reason about (no hidden inefficiencies, failure 
paths are more visible)
+ Makes generic code easier to define and more efficient for many types
- Makes value types difficult to define: a value type must store all 
state and do all manipulation indirectly, via a reference-counted 
pointer; all methods must check the pointer against null; all mutating 
methods must use a copy-on-write approach
- Needs copy-on-write (COW) approaches in defining object types and COW 
is error-prone because it relies on the programmer remembering to always 
ensure a unique copy prior to changing the object
- Can become a notable difference from C++ (and consequently a 
contention point for C++ programmers who are considering migrating to 
D): arbitrary cost of construction hurts C++ in many places, but it has 
contained the situation with a combination of complexity, discipline, 
and acceptance of inefficiencies.

Any tie-breaking arguments, I'm all ears.


Andrei