Microsoft working on new systems language

[Chris Cain]

On Tuesday, 31 December 2013 at 06:28:40 UTC, Ola Fosheim Grøstad 
wrote:
> A flexible new and good compiler level memory management 
> support that cannot be overridden gives the compiler some 
> optimization opportunities. E.g. putting objects on the stack, 
> allocating a single chunk for multiple objects, delaying init 
> and perhaps avoiding allocation.
>
> So I am personally sceptical of pushing libraries over advanced 
> compiler support. Leaving more room for analysis is usually a 
> good thing.

Well, that's certainly a good point. There's _probably_ some 
extra optimizations that could be done with a compiler supported 
new. Maybe it could make some significantly faster code, but this 
assumes many things:

1. The compiler writer will actually do this analysis and write 
the optimization (my bets are that DMD will likely not do many of 
the things you suggest).
2. The person writing the code is writing code that is allocating 
several times in a deeply nested loop.
3. Despite the person making the obvious critical error of 
allocating several times in a deeply nested loop, he must not 
have made any other significant errors or those other errors must 
also be covered by optimizations.
4. The allocation isn't passed around too much to avoid the 
analysis or isn't actually kept around sometimes for some reason

This makes the proposed optimization _very_ situational. If the 
situation does occur, it's possible that the user can use 
something like "std.allocator.StackAllocator" to do what he 
needs. Manual optimization in this case isn't too unreasonable. 
Considering the drawbacks of new and the advantages of a library 
allocation, this additional _potential_ advantage of new isn't 
enough to suggest its usage over a library solution here. Again, 
it's not a bad point, but it's just not compelling enough.

That all said,

> The issue I have with library level allocation is that the 
> compiler does not know that the code is doing allocation?

_Technically_ the compiler could also do some analysis in 
functions and figure out that it will be allocating in there 
somewhere and using that allocation later on. Think of replacing 
library calls when it's noticed that it's an allocate function. 
It's pretty dirty and won't actually happen nor do I suggest it 
should happen, but it's actually still also _possible_.