Ruling out arbitrary cost copy construction?

[Andrei Alexandrescu]

On 10/29/10 15:18 CDT, Pillsy wrote:
> Andrei Alexandrescu Wrote: [...]
>> FWIW this matter is still tormenting me. It gridlocks work on
>> ranges, algorithms, and containers.
>
> Here's my take: it seems in both cases you're arguing about
> contorting something in the name of a relatively niche construction.
> In one case, it's designing libraries around the possibility that you
> might have an expensive-to-copy value type, and in the other you seem
> to be seriously contorting the very idea of "value type" itself.

Very well put. (Why don't you post more often?)

> I'm sort of wondering where all these expensive-to-copy value types
> are going to come from. It's not like writing an expensive-to-copy
> struct is likely to be something you do by accident, right? I can't
> think of a case where someone just does it because they know better.

The typical case is value types of variable length: strings (the 
built-in offering notwithstanding), BigInt, BigFloat, STL-style 
containers, possibly even vectors and matrices (though that's almost 
always a design mistake). And then of course come types that contain 
such. So "expensive-to-copy" is a transitive property that rots 
everything upwards. In fact let me just add this to the list of pros and 
cons:

1. Arbitrary cost copy construction:

- Propagates through the membership relation, i.e. a struct with at 
least one costly-to-copy member becomes itself costly-to-copy even 
though it wasn't planning to or wasn't aware of.

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

+ Transparent for the member-of relation, i.e. a constant copy member 
keeps its containing struct also constant copy.

> A programmer coming from C is likely to naively treat D structs like
> C structs, and be fine.

Except as noted above. A C programmer might plop a couple of BigInts in 
a struct and think that they're in good shape.

> A programmer coming from Java# or a dynamic scripting language is
> probably going to be happier sticking to classes and their comforting
> and familiar reference semantics when they're getting started.
>
> That leaves programmers coming from C++, who are likely to know what
> they're getting themselves into, or more experienced D programmers,
> who again are likely to know what they're getting themselves into.
>
> I think this is a definite worse-is-better situation. Just assume
> that value types don't have randomly expensive copies in the standard
> library code, while letting people who want to take the risk of
> shooting themslves in the foot shoot themselves in the foot by having
> this(this) open an HTTP collection to Alpha Centauri if that's what
> they really want.
>
> Cheers, Pillsy

Thanks for the vote.


Andrei