Reddit: why aren't people using D?

[Rainer Deyke]

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.

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.

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

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

  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.

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

>> 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.  Also, unless I am mistaken, D can move value types
around in memory at will, which also invalidates designs that are useful
in C++.

> How does the class/struct split? I think it's an enormous source of
> confusion for C++. C++ lore clarifies that you must decide in day one
> whether a class is meant to be polymorphic or monomorphic. Unfortunately
> that can't be expressed in the language, hence the weird cases with
> deriving from std::vector or getting polymorphic values unceremoniously
> sliced. Avoiding such mistakes are important things that C++ users must
> learn because there's nothing in the language stopping them from doing
> such nonsensical things; D very elegantly breaks that pattern by
> defining the language to only allow meaningful constructs.

On the contrary, the default in C++ is that a class can be used both as
a value type and through a pointer as a reference type.  Even in D,
value types can be turned into value types

Yes, when you copy class instances, it might be a bad idea to use the
class as a base class.  And conversely, if you use the class as a base
class, it might be a bad idea to pass around instances of the class by
value.  It would be easy to forbid both of these at the language level,
and almost as easy to fix them by creating non-slicing polymorphic value
types.  But the class/struct split in D goes much deeper than that.


-- 
Rainer Deyke - rainerd at eldwood.com