On Tue, Apr 26, 2022 at 06:20:50PM +0000, Salih Dincer via Digitalmars-d wrote:
> As long as the Voldemort type lives on, does int x, y legally live on?
> 
> ```d
> auto getPoint()
> {
>   int x, y; // major issue
> 
>   enum type = "2D";
>   struct Point(string Id)
>   {
>     static int _x = 1024;
>     static int _y = 768;
>     string toString() {
>       import std.format;
>       return format("Limit: %dx%d px.",
>                                _x, _y);
>     }
>     void set(int a, int b) { x = a; y = b; }
>     uint area() { return x * y; }
>     auto get() { return this; }
>   }
>   auto px = Point!type();
>   return px.get;
> }
> ```

That's a closure over x and y, so yes, they will live on.  The compiler will detect that a closure is required, so it will allocate them on the heap instead of the stack, and the struct Point will have a hidden context pointer that points to the heap allocation that contains the values of x and y.  As long as a Point instance still exists that points to the allocated block, the GC will not collect it.

In general, though, I don't recommend closing over local variables in a struct, unless you mean to share those variables across copies of the struct.  In the above example, if you call getPoint twice, you will get two Point structs pointing to different copies of x and y.  But if you make a copy of either struct, you will end up with two structs that share the *same* set of x and y values (so changes to one will be seen by the other), which may or may not be what you want.  This can make for rather confusing behaviour if these structs get passed around to other code.

My usual practice is to avoid such struct closures, and to store independent copies of x and y inside the struct itself instead (just make them private and move it into a separate module if you're paranoid).


T

-- 
"A one-question geek test. If you get the joke, you're a geek: Seen on a California license plate on a VW Beetle: 'FEATURE'..." -- Joshua D. Wachs - Natural Intelligence, Inc.