Ruling out arbitrary cost copy construction?

[Pillsy]

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.

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.

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

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