D Core Guidelines?

[bachmeier]

On Saturday, 2 September 2023 at 16:08:43 UTC, Bruce Carneal 
wrote:

> D, as you will have noted from the responses so far, appeals to 
> programmers with widely differing interests and experience.  
> Additionally I, and I imagine many others, adopt a different 
> style when writing performance critical library components than 
> I do when knocking out a command line utility.  You may have 
> better luck getting what you're looking for if you provide some 
> anticipated use scenarios.

Yeah, this is what I was getting at in my comment. I use D more 
than anything as a scripting language (I no longer write Ruby). 
In those cases, I don't worry about performance at all, the code 
will be fast no matter how I write it, and the garbage collector 
is the best thing ever. Sometimes I use it for reading in large 
datasets, and I might disable/avoid the garbage collector if it 
has a practical impact. Then there is the Mir case, where the 
goal is performance at all costs, so that's written in betterC. 
Others want extremely safe code, so they put attributes 
everywhere. In the absence of a use case, you just can't tell 
people how to write their code.

C++, on the other hand, is focused mainly on cases where you want 
performance. Folks adopting that mindset with D will give silly 
responses to questions. One example that comes to mind from years 
ago was a piece of advice about string concatentation. The person 
giving the advice implicitly assumed the user wanted to prevent 
allocation above all else. That just isn't a consideration for 
much (most?) of the D code that's written using strings.