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

[forkit]

On Tuesday, 7 June 2022 at 19:42:00 UTC, Ola Fosheim Grøstad 
wrote:
>
> It is very difficult to get good usability as long as most 
> users coming from other languages have a rather firm 
> interpretation of what `private` means.

No, they (we) come with a firm interpretation of what 
encapsulation means, because they (we) can actually make things 
private, and that contract can be enforced at compile time - they 
(we) don't have to 'remember' not to make mistakes.

C++ friend is not something you should be using all the time. It 
breaks encapsulation. It does not enhance it, in any way, 
whatsoever. But there are situations where it makes things a lot 
easier, that's for sure. But it comes at the expense of 
encapsulation (just as inheritance does). But at least I can 
choose to inherit, or not. In D, encapsulation is non-existent 
(from other code within a module). There is no option to 
encapsulate it either. You're forced to do silly work arounds to 
just get a pseudo encapsulation.

But more importantly, the language they're 'most likely' coming 
from, if they do object-based, or object-oriented programming, 
will be C++,C#, Java. And all these languages sought to enhance 
the options available to the progrommer to obtain, to obtain 
greater encapsulation, to various degrees - but D sought to 
weaken it, intentionally, by making *everything* your friend. You 
got no choice in D. D's approach (without an option like 
@private), encourages less encapsulation, by design, because you 
'by default' consider everything your friend. There is no need to 
think about encapsulating components within a module. Some argue 
this is the whole point. But just go look at some of the modules 
in phobos ;-)

Faced with the choice of using an object-based, or 
object-oriented approach to the design of a solution, without a 
@private option, D would NOT ever be my choice of language. Other 
langauges are already better suited for such a design.