Are there any default dmd optimizations

[Andrei Alexandrescu]

On 2/26/13 2:56 AM, foobar wrote:
> DDoc isn't part of the language but rather part of the compiler,
> nevertheless it has its downsides. Being part of the compiler means that
> the compiler needs to be changed to address those and it isn't even
> written in D! The end result is all sort of additional auxiliary D
> utilities to post-process this in order to address some of those issues.
> Hence, A prime example of the failure that I'm talking about.
>
> unittest is worse, it is indeed part of the language so now the
> _language grammar_ needs to be changed to fix the problems with it, such
> as not having test names. A far better solution practiced in all other
> major languages is to use annotations and in fact, there probably
> already are similar D frameworks, thus exhibiting the same problem of
> multiple conflicting implementations you wished to avoid.

I think this is unnecessarily negative because far as I can tell ddoc 
and unittest are features that people use and appreciate. BTW no need to 
change the grammar for improving unittests, only an API is sufficient - 
consider e.g.:

@"name" unittest { ... }

or simply

unittest {
    testName("name");
    ...
}

One can find negatives of most any feature.

> Additional such problems - the AA issue which has been going own for
> years now. The endless discussions regarding tuples.

There are plenty of cases in which discussions have been concluded with 
successful improvements. We can't tell people what to work on, so some 
are longer than others.

> It seems that D strives to bloat the language with needless features
> that really should have been standardized in the library and on the
> other hand tries to put in the library things that really ought to be
> built into the language to benefit from proper integration and syntax.

If I wanted to clarify how subjective that is, I couldn't have written 
it better :o).

> The latest case was the huge properties debate and its offshoots
> regarding ref semantics which I didn't even bother participate in.
> Bartosz developed an ownership system for D to address all the safety
> issues raised by ref *years ago* and it was rejected due to complexity.

That was for threads.

> Now, Andrei tries to achieve similar safety guaranties by giving ref the
> semantics of borrowed pointers. It all seems to me like trying to build
> an airplane without wings cause they are too complex. Rust on the other
> hand already integrated an ownership system and is already far ahead of
> D's design. D had talked about macros *years ago* and rust already
> implemented them.

I think Rust has gone a bit too far with with complexity of the type 
system. There's only this much karma one can spend for such. In my 
opinion we're in better shape than Rust in that particular regard.

>> We do have a significantly better D culture than the C++ one. For
>> example, C++ relies heavily and unapologetically on convention for
>> writing correct, robust code. D eschews that, and instead is very
>> biased towards mechanical verification.
>>
>
> I call bullshit. This is an half hearted intention at best.
> @safe has holes in it, integers has no overflow checks, ref also has
> holes, Not only D has null pointer bugs but they also cause segfaults.

Last one is different. Anyhow, it is a certainty we regard e.g. @safe 
hole as problems that need fixing, which is a significant cultural 
difference. At any rate, I agree one ought to be suspicious whenever 
someone claims "Language X's culture is better than language Y's culture."


Andrei