Are there any default dmd optimizations

[foobar]

On Monday, 25 February 2013 at 22:26:33 UTC, Walter Bright wrote:
> On 2/25/2013 2:00 PM, foobar wrote:
>> On Sunday, 24 February 2013 at 22:28:46 UTC, Walter Bright 
>> wrote:
>>> 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.
>
> On the contrary, I think it has turned out rather well. Another 
> success story of baking certain things into the language is 
> Ddoc. Unittest is a third. They've been big wins for D.
>
> None of those strictly has to be in the language - they can be 
> done by convention and 3rd party tools. Nevertheless, 
> convenience, standardization and mechanical enforcement of a 
> convention seem to work better than applying religious zeal to 
> enforce a convention.
>

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.

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.

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.

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

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