Ruling out arbitrary cost copy construction?

[Jonathan M Davis]

On Friday, October 29, 2010 11:05:02 Andrei Alexandrescu wrote:
> > As for eager-coping, it's a _value type_, of _course_ it's going to be
> > copied eagerly. ints, floats, bools, etc. _all_ copy eagerly. How can
> > you expect anything else? It's quite explicit that that's how value
> > types work. So, if you write a struct where copying is expensive, you're
> > asking for trouble and should know it. The only real issue with it that
> > I see is the non-obvious places where copying take place. But if you
> > tried to make it so that structs didn't copy eagerly, then you're making
> > it so that they're not value types anymore which will increas overheard
> > and goes against what structs are meant for.
> 
> In fact reference counting allows you to define value types with cheap
> copy construction, so the above is incorrect.

I think I misunderstood what you meant and was thinking reference type rather 
than ref-counted.
> 
> > C++ doesn't stop you or help you from being stupid about expensive copy-
> > construction. Why should D? Sure, it sucks when your program is slow, but
> > we have classes which are reference types and don't have this problem.
> > So, if you want a reference type, there it is. I don't see how anyone
> > could expect expensive copying not to result in poor performance for a
> > _value type_.
> 
> That means ranges need to define moveFront, moveBack, moveAt, and
> countless othed contortions in library code and client code alike. I
> think the view you're conveying is overly simplistic.

I'm arguing that you do _not_ define those and that you let user code fend for 
itself. If a programmer is foolish enough to write code with overly expensive 
postblit constructors, then they're just shooting themselves in the foot.

- Jonathan M Davis