Reddit: why aren't people using D?

[Rainer Deyke]

Walter Bright wrote:
> Rainer Deyke wrote:
>>   - Implementation inheritance of value types, even without actual
>> polymorphism, is useful.  See, for example, the curiously recurring
>> template pattern (and all of its uses).
> 
> You can do this with 'alias this'.

Composition instead of inheritance?  Doesn't work if I need virtual
functions.

>>   - 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.
> 
> iostream isn't a good example of design <g>.

I fully agree, but /this particular aspect/ of iostreams isn't an
example of bad design either.

How would you do this in D?  Turning iostreams into reference types
isn't the answer, especially if this means losing RAII.
Non-polymorphics iostreams is also no-go.  I suppose you could create a
polymorphic reference-type wrapper around a pointer to the actual
iostream struct, but that's a lot of extra work that isn't necessary in C++.

>>     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.e. they're a mess. You just confused the heck out of me.

I don't see what's confusing about this.

Most iostreams are non-copyable, i.e. the following just plain doesn't
compile:
  stream_type a;
  stream_type b = a;

Iostreams are not reference types, at all.  It's not possible for one
iostream to (accidentally or intentionally) alias another iostream.
There are not idiomatically allocated with 'new'.  Therefore they avoid
the problems of having reference types in the language.  Long distance
bugs with iostreams are highly unlikely.

Iostreams are passed as references - real references, with the 'T&'
syntax, equivalent to 'ref T' in D - because that's the only way to pass
them around.  The callee always knows they are receiving a reference,
because the '&' is an explicit part of the function signature.


>>   - 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.
> 
> That philosophy conflicts with using . for values and -> for references.

Are you deliberately trying to misunderstand me?

In C++, for any type T, there is a type T* (and shared_ptr<T> and
inclusive_ptr<T> and so on).  T is a value type, always.  T* is a
pointer to a value of type T, but T* itself is still a value type.

Given 'T* p;', 'p.x' accesses a member of 'p', while 'p->x' or '(*p).x'
accesses a member of the value referenced by 'p'.  Always, consistently,
whether 'T' itself is a primitive type, a class, or even itself a
pointer type.

> The capability of being able to move value types is deliberately
> designed in. It's there for the obvious reason of being able to create a
> moving garbage collector, and for the more subtle reason of being able
> to optimize away many more cases of copy-construction and destruction.

I know.  Still, it invalidates valid C++ idioms.  If there was some way
to say "this struct cannot be moved", or even a hook function that is
called before/after/during each move, then those idioms might still be
valid.


-- 
Rainer Deyke - rainerd at eldwood.com