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
