scope(~this)

[Basile B. via Digitalmars-d-learn]

On Tuesday, 14 March 2017 at 14:35:11 UTC, Inquie wrote:
> On Tuesday, 14 March 2017 at 05:33:28 UTC, thedeemon wrote:
>> [...]
>
> Complexity is in the eye of the beholder. Children think many 
> things are complex when they are not.
>
> If a library solution could be created that is as seamless as a 
> language solution, then I guess it would work.  The downside of 
> a library solution is uniformity of syntax and added verbosity.
>
> There is really no any arrays to keep track of or anything like 
> that matter you stated. It requires creating a delegate to wrap 
> the scope block and a copy of the variable to one on the heap. 
> The GC uses arrays and that happens regardless. No reason for 
> the compiler to create a new array.
>
> 3 steps:
>
> 1. Compiler copies local variables to heap(the "closure" part, 
> which actually means it is not closing anything as a normal 
> delegate would require).
>
> 2. The compiler creates a delegate. No big deal, does this in 
> many places.
>
> 3. The compiler calls all the delegates on destruction. The 
> only new part. But not difficult.
>
>
>
> Create a ScopeThis(...) and adds no extra overhead would be 
> nice but I see that as being more complex. How can we determine 
> what are variables that need to be copied to the heap? How can 
> we hook in to the ~this? (can't have multiple ones, can we?)
>
> If you can come up with a working ScopeThis that doesn't have 
> any more overhead than a language version, I'd be all for it, I 
> don't know or see how it could be done.
>
>>>>>       [...]
>
> Must determine that x is a variable(hard?) and copy it to the 
> heap(easy). Must create access to any local functions 
> used(e.g., if dealloc is local). Then must hook in to ~this to 
> execute the code.
>
> It would be nicer to not have to use a string but it would work 
> easy since we could use a mixin and modify the string easily 
> once we could parse it.

I was not sure to answer yesterday because the conversation 
turned on the COM thing. I wanted to say that you can use a mixin 
template because they can introduce destructors that are called 
automatically with the aggregate destrcutor

mixin template Foo(T)
{
     T x;
     void foo()
     {
         alloc(x);
     }
     ~this() // auto-called by the target aggregate
     {
         dealloc(x);
     }
}

class bar
{
     mixin Foo!Stuff;
}