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