Safe Regions with Deterministic Destruction

[ag0aep6g]

On Tuesday, 27 October 2020 at 18:35:40 UTC, Ola Fosheim Grøstad 
wrote:
> On Tuesday, 27 October 2020 at 18:24:47 UTC, ag0aep6g wrote:
>> On Tuesday, 27 October 2020 at 16:56:40 UTC, Ola Fosheim 
>> Grøstad wrote:
[...]
>>> class A { int x; }
>>> class B { A a; }
>>>
>>> A oddball() {
>>>     scope B b = new B;
>>>     b.a = new A;
>>>     return b.a;
>>> }
>>
>> `oddball` is neither a class nor a struct; it's a function.
>
> Yes, obviously, but it it passes as a class.

I didn't understand what you mean by "passing as a class". I 
guess you mean that it returns a class.

[...]
> Well, but "scope B b = new B;" will stack allocate, right? So 
> it is allocated on the stack like a struct. I suspect a user 
> would expect b.a to be restricted as it would have been as a 
> struct.

Ok, I see your point now. I wasn't thinking about `scope` as an 
indicator for stack allocation at all. As far as I'm aware that's 
just a possible optimization, not a guarantee. And it's somewhat 
independent from DIP 1000's `scope`.

If it becomes more than an optimization, then yeah it might make 
sense to not view `scope` class variables as indirections in that 
case. Or maybe it wouldn't be sound. I really have no idea.

> But yes, I get the "one indirection" thing you mentioned. The 
> question is, is that useful enough? Is that something users 
> will understand?

It's fairly obvious to me that `scope` is not easy to understand. 
The buggy implementation and insufficient documentation don't 
help. At the same time, I am myself not interested in finding a 
better solution to the problem.

[...]
>> I'm not sure if I understand the question, but as far as I 
>> understand `scope` locals and `scope` parameters work the same 
>> for all types. (Maybe there are subtle differences in life
>
> Except that "scope B b = new B" stack allocates? Or does that 
> happen for parameters too? Does this cause stack allocation of 
> B?
>
>   f(scope B b){…}
>
>   f(new B);

I don't think so. You're right that stack allocation is a 
significant difference, but only if it is (or becomes) more than 
an optimization.