D 2015/2016 Vision?

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 6 October 2015 at 08:27:02 UTC, Ola Fosheim Grøstad 
wrote:
> 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.

scoped is not designed with the idea that it's memory safe. 
scoped is very much an @system operation. And scoped is intended 
to replace scope classes in the language, so I don't think that 
any language support is going to be added for this. It's 
something that someone who knows what they're doing and needs 
that extra bit of efficiency can do, not something that's really 
intended to be in your average D program. In most cases, anything 
that's supposed to live on the stack should have been a struct 
anyway. It's just an issue when you want to use something on the 
stack in a particular case whereas it normally would be on the 
heap. And given D's lack of flow analysis and Walter's insistence 
on not adding it, I rather doubt that he's going to be big on the 
idea of having the compiler decide that it's safe to allocate a 
class object on the stack rather than the heap. But I don't 
remember him ever saying anything on that topic specifically.

- Jonathan M Davis