Are there any default dmd optimizations

[foobar]

On Tuesday, 26 February 2013 at 19:53:11 UTC, Walter Bright wrote:
> 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.
>

All of the above describes the benefits of having standardized 
documentation and I agree with that. That has nothing to do with 
DDoc's specific design compared to other similar efforts. A quick 
survey of languages shows that Ruby, Python, Java, C#, and many 
others all have the same benefits but non has the doc generator 
built into the compiler/vm with all the problems this entails.

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

Same as above. You compare again to C++ and ignore the provably 
successful models of _many_ other languages. Ruby for instance 
really shines in this regard as its community is very much 
oriented towards TDD. Java has such a successful model with its 
JUnit that it inspired a whole bunch of clones for  other 
languges and you completely ignore this. Instead you discuss the 
design of a new car based on experiences of horseback riders.

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

I'm familiar with the history of AAs in D and how they came to be 
this horrible mess. Yet, templates in D are ancient news by now 
and the problem hadn't been fixed and not due to lack of effort. 
The problem is again - applying common c++ wisdom and trying to 
maintain inconsistent semantics.


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

Yes, but this conflicts with your statement of intention towards 
verification machinery for safety. Of course I can implement 
whatever I need myself but what ensures safety is the fact that 
the default is safe and the language forces me to be explicit 
when I choose to sacrifice safety for other benefits. You see, 
*defaults matter*. I can use an option type in D and still get 
null pointer segfaults whereas in Rust I cannot get a null value 
without an explicit option type which I am forced to check.
Another case in point - both Germany and Austria have an option 
to sign an organ donor card when getting a driver's license. 
Germany requires to tick the box if you want to join the program, 
Austria requires to tick the box if you do *not* want to join. 
Austria has a much higher percentage of organ donors.

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

irrelevant. See previous comment.

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

I'm not sure rust has such a feature as it is much more 
functional in style than D. If I'm not mistaken, "debug" in Rust 
is used as one of the logging macros.