Are there any default dmd optimizations

[Walter Bright]

On 2/26/2013 2:10 PM, foobar wrote:
> 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.

Building ddoc into the compiler means it has access to the semantic information 
that compiler provides, and it uses that information. If it is not built in to 
the compiler, then the options are:

1. require the user to type the information in twice
2. add parsing and semantic analysis capability to the doc generator

I find (1) to be an unacceptable user experience, and (2) to be not viable given 
our limited resources.

BTW, Javadoc apparently can only generate HTML. As Andrei has demonstrated, Ddoc 
can generate html, pdf, and ebooks without changing the Ddoc comments. I'm 
curious what fundamental advantage you believe Javadoc has over Ddoc.


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

They're not that much different - except in one significant aspect. JUnit (for 
example) has a plethora of websites devoted to tutorials, cookbooks, how-tos, 
best practices, etc. D unittest is so simple there is no need for that. Anyone 
can be up and using D unittests in 2 minutes. The how-to is one slide in a 
presentation about D. Nobody is going to write a book about D unittest:

     http://www.amazon.com/JUnit-Action-Second-Petar-Tahchiev/dp/1935182021

That's a 450 page, $30 book on JUnit, in its second edition because it's so 
complicated.

I believe the success of unittests in D speak to the value of making it so 
simple to use.

That said, with the new UDA in D, you (or anyone else) can write a "DUnit" and 
present it to the community. I doubt you'll find it worth the effort, though, as 
unittests work very well.


>The problem is again - applying common c++
> wisdom and trying to maintain inconsistent semantics.

I'm curious how you ascribe builtin AA's, which C++ does not have and will never 
have, to applying C++ wisdom. As I said, D's AA's were inspired by my experience 
with Javascript's AA's.


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

Designing *anything* is a compromise among mutually incompatible goals. In no 
way are we going to say principle A, worship A, use A as a substitute for 
thought & judgement, and drive right over the cliff with a blind adherence to A.

For example, try designing a car where safety is the overriding concern. You 
can't design it, and if you could you couldn't manufacture it, and if you could 
manufacture it you couldn't drive it an inch.

All language design decisions are tradeoffs. (And to be pedantic, integer 
overflows are not a memory safety issue. Neither are null pointers. You can have 
both (like Java does) and yet still have a provably memory safe language.)


> 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 agree they matter. And I doubt any two people will come up with the same list 
of what should be the default. Somebody has to make a decision. Again, tradeoffs.