Are there any default dmd optimizations

[foobar]

On Sunday, 24 February 2013 at 22:28:46 UTC, Walter Bright wrote:
> On 2/24/2013 12:57 PM, Andrej Mitrovic wrote:
>> On 2/24/13, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>>> Yeah, which just adds the confusion, because all it does is 
>>> enable debug
>>> bocks.
>>
>> The feature almost doesn't pay its weight. I mean technically 
>> you can
>> use -version=Debug and then use version(Debug) blocks. All 
>> `debug`
>> does is saves a little bit of typing.
>
> I should explain the reasoning for this.
>
> I've talked to many C/C++ programming managers. They lament 
> that every C/C++ coding group feels compelled to reinvent their 
> own debug macro scheme. This makes it pointlessly difficult to 
> share code between groups.
>
> It's not that unlike how pre-C++98 code bases all had their own 
> "string" class.
>
> By baking one scheme into the language, people will rarely feel 
> a need to reinvent the wheel, and will go on to more productive 
> uses of their time.

This is a fallacy caused by the "culture" of c++ programmers - 
there is exactly *zero* benefit in baking this into the language.
Yes, I agree with the sentiment that there should be a standard 
way to save programmers the hassle and all that. The correct 
solution to that is a culture of cultivating standard conventions 
and "convention over configuration". E.g. Java has many such 
convections followed to a level of religious zeal, such as using 
camelCase everywhere and using PascalCase for types, etc, etc. 
None of which is _enforced by the language_.
On the other hand, many major c++ libraries re-invent "string" 
even though there exists already std::string and there are even 
libraries that advocate _avoiding_ the use of stl entirely, all 
for the perceived benefit of efficiency which is a prime example 
of premature optimization. Even if there is efficiency gain in a 
specific implementation, ideally it should have been used to 
improve the standard stl::string but trying to change anything in 
the c++ standard is futile - you can't just send a pull request, 
you need to pass boat loads of red tape and wait a decade or two 
for the next version, thus causeing this major NIH attitude.
All of this is to say, that instead of trying to "fix" the c++ 
culture in D, we should try to create a *better* D culture. When 
you're buying an airplane ticket, what do you say to the travel 
agent? The human reflex of "I don't want to go to ___" doesn't 
get you a ticket anywhere. This feature is analogous - it's 
designed to not allow c++ misbehavior, instead of actually 
thinking what we do want and how best to achieve that. 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.