Ruling out arbitrary cost copy construction?

[Jonathan M Davis]

On Friday, October 29, 2010 08:59:51 Andrei Alexandrescu wrote:
> 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

Honestly, what I expect to happen if constant-copy cost is expected is that code 
won't be written that way and the code that expects a constant-copy cost is 
going to be slow. Really, I'd say that in the general case, either arbitrary 
copy construction is going to be expected, and there will be code which assumes 
constant-copy cost and so is slow, or constant-copy cost construction is going 
to be expected and any postplits which don't have a constant-copy cost will are 
going to be inefficient in various places.

I really don't think that you have any hope of enforcing either scheme. 
Programmers just won't think about it in the general case. So, unless the 
"mandatory refcounting for value type" (and I have no clue how you'd do that) is 
actually enforced, you can't enforce either, and you _will_ have inefficiencies. 
It's just a question of where and what kind.

If anything, I'm inclined to say that we assume that the postblit is O(1) and 
let the programmer worry about any inefficiencies. We can point out that anything 
worse that O(1) will be a performance problem, but it seems to me that any 
attempt to either accomodate arbitrary cost postblit constructors or to try and 
use any kind of scheme which forces programmers to write postblits in a certain 
way is too complicated and doomed to failure. And even if it works, it will be 
highly annoying to deal with.

- Jonathan M Davis