Reddit: why aren't people using D?

[Andrei Alexandrescu]

Rainer Deyke wrote:
> Andrei Alexandrescu wrote:
>> Rainer Deyke wrote:
>>> 1. C++'s object model, complete with polymorphic value types,
>> What designs make good use of polymorphic value types?
> 
> In a way, that's a loaded question, since C++ classes don't stay
> polymorphic when passed around by value.  Actual polymorphic value types
> that stay polymorphic when copied would be much more useful.  However,
> even the limited polymorphic value types of C++ are useful.

I'll try to briefly reply to this (I've been offline since yesterday's 
storm when a thunder fried the cable modem).

> Let's see:
> 
>   - Implementation inheritance of value types, even without actual
> polymorphism, is useful.  See, for example, the curiously recurring
> template pattern (and all of its uses).
> 
>     And, yes, you can achieve similar results in D by using template
> mixins, but this is a specialized mechanism where C++ manages to do with
> the same generalized mechanism used for polymorphism and interface
> inheritance.
> 
>     I use inheritance of value types all the time.

Well I use it sometimes too, but it's so fraught with peril that 
virtually all coding standards I've ever seen, all books and magazine 
articles on the topic, all pundits, say one thing: don't. Better use 
composition.

>   - Polymorphic references to value types are often useful.  D has
> references to value types (in the form of 'ref' parameters and pointers)
> but these are not polymorphic.  As an example, I would name the standard
> C++ iostream.
> 
>     They're value types (non-copyable for the most part, but stored
> directly instead of as pointers, with RAII), but they're often passed
> around as polymorphic references.
> 
>     I use polymorphic references to value types occasionally.

I don't know what polymorphic references to value types mean, and I 
don't think iostreams are representative for the matter, or a good 
design in general.

>   - C++ makes a clear distinction between a reference and the thing
> being referenced.  Even if value types and polymorphism were mutually
> exclusive, this distinction would be useful.  All types are consistently
> treated as value types, even those types that reference another object.

This is incorrect. C++ references are not value types. The design of 
references in C++ is particularly poor.

>   I *like* having to write 'gc_ptr<Object> p;' instead of 'Object p;'.
> I *like* having to write 'p->f();' instead of 'p.f();'.  It keeps my
> code clearly and more explicit.

I understand, but that's a judgment call (e.g. explicit calls instead of 
operator overloading). Other people prefer the opposite.

>   - C++ does not have separate rules for value types and reference
> types.  All types are implicitly value types; values of all types can be
> placed on the heap.  This simplifies the language by having just one set
> of rules instead of separate rules for classes and structs.  Again, this
> unification would be useful even if it was an error to declare a
> variable of a polymorphic type as a direct variable.

Again, C++ has references which kind of introduce separate and very 
different rules.

>>> deterministic destructors,  arbitrary copy constructors, and optional
>>> lack of default constructor.
>> Struct have that except for default constructor. In D, currently default
>> constructors cannot execute code. This is a limitation that we might
>> need to address, although it has some advantages.
> 
> There are things that copy constructors can do that the post-blit
> operator can't do.

Yes, mostly wrong things. I think it would be a huge loss if D copied 
C++'s model.

> Also, unless I am mistaken, D can move value types
> around in memory at will, which also invalidates designs that are useful
> in C++.

C++ copy+destroy sequence has been an absolute pest for years. Rvalue 
references fix that by adding another layer of complexity. I'm very 
happy D didn't inherit that.


Andrei