Ruling out arbitrary cost copy construction?

[Andrei Alexandrescu]

On 10/29/10 12:53 CDT, Jonathan M Davis wrote:
> 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.

If the feature had nothing else going for it except being in C++ it 
would have been eliminated. But value types are a very solid 
abstraction. We definitely want to support them in D.

All - please do not take only one isolated argument from those I listed 
and focus discussion on it alone. It can only lead to stilted views.

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

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


Andrei