auto arr = [1, 2, 3] should be a static array, not a GC allocated array

ryuukk_ ryuukk.dev at gmail.com
Sat Jul 23 15:09:11 UTC 2022


On Saturday, 23 July 2022 at 14:56:48 UTC, Don Allen wrote:
> Personally, I hope Walter ignores this conversation. I think 
> the current syntactic distinction (presence or absence of a 
> constant length) between static and dynamic arrays is fine and 
> whether a dynamic array is gc-allocated or stack-allocated 
> seems to me to be a compiler optimization issue. I would think 
> that if the compiler can prove that the array doesn't need to 
> be re-allocated due to expansion and if allocation on the stack 
> provides a sufficient lifetime, then it can stack allocate. And 
> we should only care whether dmd does this optimization if it 
> becomes clear that it is important in a lot of use cases, which 
> I doubt.

I would be fine if the distinction was made by the compiler, but 
in critical performance scenarios, i don't want to gamble wether 
the compiler will optimize something or not

I want to make sure that my intent is perfectly understood by the 
compiler

I don't want any ambiguity, when i write the code, and more 
importantly when i read it

"Oh it is `auto arr = [1, 2, 3]` will it be stack allocated? hmm 
idk, let me decypher this whole algorithm again`"

> And regarding that optimization, as hardware has gotten faster 
> and faster (remember the Cray 1 "supercomputer"? It had an 80 
> mhz clock frequency), we have become more and more guilty of 
> premature optimization. The flip side of that is that is the 
> amount of software we all use daily that is written in 
> languages like Python, Javascript or PHP that are perhaps 2 
> orders of magnitude slower than D and still provide adequate 
> performance even on our phones.
>
> My opinion.
>
> /Don

Not everyone develop for High End devices

Some people are fine paying more $$$ for higher Cloud instance 
tier, some are not

I personally stick to the cheapest to host my stuff, and my care 
made me save lot of money, and my programs are all fast, no 
compromise, and the language shouldn't cater to the lower common 
denominator, the developer should make that choice






More information about the Digitalmars-d mailing list