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 (seewebsiteforem...@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
