Ruling out arbitrary cost copy construction?

[Jonathan M Davis]

On Friday, October 29, 2010 10:15:09 dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s
> 
> > Any tie-breaking arguments, I'm all ears.
> > Andrei
> 
> Uh...How about that if people want C++, they know where to find it?  I
> think familiarity to C++ programmers is The Wrong Reason (TM) to allow
> arbitrary cost copy construction.  Furthermore, I don't see crufty old C++
> programmers as being more important to D than people from other
> backgrounds.  I see D users coming from a variety of backgrounds:
> 
> 1.  Crufty old C/C++ programmers.
> 
> 2.  People who like dynamic languages but need more speed and ability to do
> low-level work.  D is about the most flexible
> close-to-the-metal/efficient/statically typed language out there.
> 
> 3.  Java/C# programmers who want a language that isn't absurdly verbose.
> 
> 4.  New programmers who don't have much already invested in any other
> language and want something advanced, modern and w/o tons of legacy cruft.
> 
> The first **may** want eager copying.  The latter three almost certainly
> won't.

Except that how many of those other languages _have_ copy construction? Java 
doesn't. C#'s classes obviously don't, and IIRC, they're structs don't either 
(though they may - it's been a while since I used C#). If we're talking about a 
feature that's pretty much only in C++, then it's a question of whether the C++ 
programmers are going to be confused and/or surprised and whether someone who 
has never dealt with such a feature would be confused and/or surprised. Also, 
for the non-C++ folks who aren't familiar with a feature, they're not going to 
know about it anyway, so whether you follow C++ or not is irrelevant to them 
while it is _not_ irrelevant to the C++ programmers.

By no means do I think that  we should do everything in a particular way just 
because C++ did it, but particularly when dealing with a feature that is C++-
centric, we need to be aware of how what we do will affect C++ programmers.

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.

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_.

- Jonathan M Davis