D 2015/2016 Vision?

Ola Fosheim Grøstad via Digitalmars-d digitalmars-d at puremagic.com
Tue Oct 6 01:27:00 PDT 2015


On Tuesday, 6 October 2015 at 06:45:47 UTC, Jonathan M Davis 
wrote:
> On Monday, 5 October 2015 at 23:08:37 UTC, bitwise wrote:
>> Well, again that has it's pros and cons. This is why I just 
>> want a normal language solution like DIP74.
>
> They're not the same thing at all. scoped is supposed to put 
> the class on the stack, not the heap. And it's not ref-counted. 
> It's so that you can create a class object in place, use it, 
> and throw it away without doing any heap allocation. 
> Essentially, it allows you to use a class as if it were a 
> non-copyable struct. Even if we end up with ref-counting 
> supported in the language, it doesn't obviate the need for 
> scoped classes. They're for different use cases.

Why not leave stack allocation of objects to the compiler, like 
inlining? Then add a "@stack" constraint that will make the 
compilation fail if the compiler is unable to put it on the stack?

You need the compiler to prove that that the life time of the 
object is shorter than the stack frame in order to have memory 
safety anyway.



More information about the Digitalmars-d mailing list