Are there any default dmd optimizations

[Walter Bright]

On 2/25/2013 11:56 PM, foobar wrote:
> DDoc isn't part of the language but rather part of the compiler, nevertheless it
> has its downsides.  [...]
> unittest is worse,

I think you're missing something gigantic. Before D had ddoc, the documentation 
for Phobos was TERRIBLE - it was mostly missing, and the rest would describe 
something that had no resemblance to what the code did. Adding Ddoc completely 
revolutionized this. It's like night and day. Sure, you can pick at Ddoc's flaws 
all day, but without Ddoc, the Phobos documentation would have remained utter s**t.

Yes, one could use Doxygen. One could hope an up-to-date version exists on all 
the platforms D is on. One could nag people to use it. One could argue with 
people who wanted to use a different doc generator. And one could look at 
typical C and C++ projects, which use no documentation generator at all, and 
pretty much have no documentation or have documentation as bad as the pre-Ddoc 
Phobos docs.

Having Ddoc always there, always installed, always up to date, with literally 
zero effort, tips the balance. It gets used. It raised the bar on what is 
acceptable D code - it looks wrong without Ddoc documentation. By tipping the 
balance I mean it *revolutionized* D code.

The same goes for unittest. How many C/C++ projects have you run across that 
have unit tests? Again, yes, you can use 3rd party tools (of which there are a 
plethora). You can try to use multiple libraries that use different unit test 
frameworks. You can look at Phobos before unittest and see that it was pretty 
much completely untested.

Unittest in the language, always there, always installed, zero effort, 
completely changed the game. I'm very pleased at the depth and breadth of 
unittests in Phobos. I have no doubt that would not have happened without unittest.

Sure, you can pick all day at the flaws of unittest, but you'd be missing the 
point - without builtin unittest, there'd be nothing to pick at, because people 
would not have unit tests.


> Additional such problems - the AA issue which has been going own for years now.
> The endless discussions regarding tuples.
> 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.

A little history is in order here. AA's were built in to the language from the 
beginning, a result of my experience with how incredibly useful they were in 
javascript. This was many years before D had templates. There was no other way 
at the time to implement them in a nice manner (try doing it in C, for example).

D's improving generics has enabled them to be redone as library features.


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

Bartosz' ownership system was intended to support multithreaded programming. It 
was and still is too complicated. I've been working on another design which 
should serve the purpose and will need nearly zero effort from the programmer 
and it won't break anything. There was some discussion last fall on the n.g. 
about it.


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

Yes, and those are bugs, and we have every intention of fixing all of them.


> integers has no overflow checks,

This has been discussed ad nauseum. To sum up, adding overflow checks everywhere 
would seriously degrade performance. Yet you can still have overflow checking 
integers if you build a library type to do it. See std.halffloat for an example 
of how to do it. It fits in with your suggestion that things that can be done in 
the library, should be done in the library.

> ref also has holes,

Yes, and we are actively working to fix them.


> Not only D has null pointer bugs but they also cause segfaults.

D now has all the features to create a library type NotNull!T, which would be a 
pointer type that is guaranteed to be not null.


>>> In fact there are many such "not c++"
>>> features in D and which is why I find other languages such as rust a *much*
>>> better design and it evolves much faster because it is designed in terms of -
>>> what we want to achieve, how best to implement that.
>>
>> How does rust handle this particular issue?

I presume rust does not have an official answer to the debug conditional issue 
and leaves it up to the user?