Rainer Deyke wrote:
Andrei Alexandrescu wrote:
So the problem exists since you are trusting the programmer to avoid it.
The slicing problem exists in the sense that it is possible for a bad
programmer to accidentally slice an object. However:
- This is not a problem with the language, but an avoidable programmer
error in the language.
Yes. There are many examples of this: memory leaks, array bounds errors,
invalid casts, that sort of thing. If you don't mind explicitly coding
around these, stay with C or C++. You'll have these errors, but if
you're careful and disciplined, it won't happen too often. It will,
however, take time and attention to avoid these errors, and to debug
them when you slip up.
In some cases, a language change can eliminate a class of bugs.
Sometimes it's worthwhile. In my experience, the cost of forbidding
polymorphic value types is pretty much zero.
- There are far more common programmer errors in C++ against which D
does not guard. For example, dangling pointers to stack variables that
have gone out of scope.
Yep. Escape analysis is tricky, but I'd like to see it in D.
- D's response to this perceived problem is far too heavy-handed,
because it disallows useful correct code.
Well, D is a systems language, so you can still get the same effect, but
it's sufficiently difficult and ugly that it is likely not worthwhile.
On the other hand, you can probably simplify it to a single template
mixin (see the thread on struct interfaces). Given that it is not a
common need (as far as I can tell) and is an inherently unsafe thing, I
believe that it is reasonable.
- I would even say that the reference type classes in D lead to more
problems. It is very easy for two objects in D to accidentally share
internal state, something that is impossible with value types.
struct A
{
int* i;
}
A a, b;
int* i = new int;
a.i = i;
b.i = i;
Hey look, they share internal state!
What mechanism for sharing state is available to by-reference objects
but not by-value objects?
