Using closure in function scope to make "real" private class members

[Dukc]

On Friday, 3 June 2022 at 22:50:06 UTC, forkit wrote:
> On Friday, 3 June 2022 at 15:41:04 UTC, Mike Parker wrote:
>> On Friday, 3 June 2022 at 12:13:47 UTC, forkit wrote:
>>
>>>
>>> Practically speaking, anyone that uses a class in D, must be 
>>> put it in its own module - no exceptions.
>>
>> That's just nonsense.
>
> How is it nonsense? I don't get it.
>

Because practical experience - at least mine - suggests almost 
the complete opposite of what you're saying. Let's take a 
practical example. Imagine I'm making a GUI label struct.
```D
struct Label
{ private ubyte[] content;

   string text()
   { //whatever...
   }

   string text(string arg)
   { //assign arg to content...;
   }

   Tuple(Font, size_t)[] getFonts
   { //Get list of fonts used, along
     //with their usage starting
     //points...
   }

   //and other members...
}
```

I'm marking `content` private because I want to keep myself free 
to change that to some other internal represenataion in the 
future.

Let's say this struct is not the only thing in the module. A 
realistic scenario would be that there are 2000 other lines that 
can access `content` if they really want to. That's not a big 
problem. Others will usually instead use the public functions of 
`Label`. If I someday decide to change the internal 
representation, it's possible that one or two things in the 
module depend on it if I'm unlucky. Those are quick and easy to 
fix, and I can fix them myself since they are in the same module.

I probably won't bother to put `Label` to it's own file just to 
avoid such an insignificant risk, and I'm pretty sure an average 
D programmer would agree with me in this.