Extending D's support for object-oriented design with private(this)

[NotYouAgain]

On Saturday, 27 April 2024 at 13:11:22 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> On 28/04/2024 1:02 AM, NotYouAgain wrote:
>> On Saturday, 27 April 2024 at 12:41:55 UTC, Richard (Rikki) 
>> Andrew Cattermole wrote:
>> 
>>     On 27/04/2024 9:18 PM, NotYouAgain wrote:
>> 
>>         so, it seems, at least 2 problems indentified in this
>>         discussion, can now be solved with private(this).
>> 
>>         1 - It can (apparently) resolve an issue with 
>> synchronized
>>         classes (I' don't pretend to understand them)
>> 
>>     It does not resolve them.
>> 
>>     It enables a programmer who knows that an issue exists to 
>> prevent
>>     it. The same programmer who wrote that module.
>> 
>>     It could be solved by doing something like this internally 
>> and
>>     automatically. No need for a DIP exposing this capability.
>> 
>> but with private(this), the issue wouldn't exist in the first 
>> place.
>
> If you use it.
>
> There is plenty of code in existence that doesn't and the 
> default isn't being suggested to be changed to require it (and 
> would affect all classes, not just synchronized due to all 
> having monitor objects).
>
> In other words, it's not a fix.

ok. thanks for explaining. I would not a promote a change this 
will break existing code.

The point of private(this) is the option to use it, not to 
enforce it on anyone.

So in this case, we are in 'agreement' then ;-)

Still, if it were available, as an option, the programmer could 
then fix it themselves.