Why did D leave the programming language shootout and will it return?

[Walter Bright]

On 9/20/2011 4:24 PM, Timon Gehr wrote:
> Basically, D code that does reasonably well at memory management is fast. And it
> is (way) easier to write fast D code than to write fast C++ code imho. Once the
> D compilers get more mature, I am sure that many D-specific optimizations will
> be added that cannot be performed on C++ code. (pure and immutable come to mind)

Once subtlety that Andrei and I suspect will have a huge impact in the future is 
that we've carefully designed the semantics of structs so they can be moved 
around in memory with a simple bitcopy.

(In contrast, C++ must invoke the copy constructor.)

Two consequences are:

1. A moving garbage collector becomes practical.

2. An object can be "transferred". For example,


void foo()
{
     A x;
     ....
     bar(x);
}

Note that there is no use of x in foo() after the call to bar(x). Thus, x can 
simply be pushed onto the argument stack (i.e. a bitcopy) and bar() is called. 
bar() takes care of the destruction of x's copy.

C++ is doomed to running the copy constructor for x to make a *copy* of it on 
the argument stack, and then must destroy the original x at the close of foo(). 
This costs:

1. an extra copy construction
2. an extra destructor call
3. extra exception handling & recovery code to deal with (1) throwing

Think of it a bit like the Star Trek transporter. Does it actually do a bit 
transfer, or does it create a copy and destroy the original? As a red shirt, I'd 
prefer the D implementation of the transporter :-)