dip1000 and preview in combine to cause extra safety errors

[forkit]

On Monday, 13 June 2022 at 23:59:56 UTC, Walter Bright wrote:
> On 6/9/2022 8:30 AM, Steven Schveighoffer wrote:
>> What is not OK is the compiler turning actual requests for GC 
>> allocation into stack allocations based on that.
> It's necessary for D generated code to be competitive.

As I work at a much higher level, conceptually, I've always 
accepted the proposition that stack allocation is much faster 
than heap allocation.

But I am curious.

How does one, these days, compare the performance of stack 
allocation vs heap allocation?

Are you also factoring into your argument (for competitively 
generated code), de-allocation? In which case, if there is a lot 
of spare memory, how does one compare the speed of stack 
de-allocation to gc de-allocation (since the more spare memory, 
the less need to GC deallocate).

I am surprised, if it's true, that modern hardware still can't 
provide heap based allocation at least as fast as stack based 
allocation. Of course, I have no idea - it's not my area, by a 
long shot - I'm just curious whether its really true, these days, 
or it's just something we accept to be true, cause it used to be 
true?