Preparing for the New DIP Process

[FairEnough]

On Monday, 29 January 2024 at 12:34:05 UTC, Atila Neves wrote:
> On Sunday, 21 January 2024 at 07:11:50 UTC, Jordan Wilson wrote:
>> On Saturday, 20 January 2024 at 22:53:15 UTC, privateWHAT 
>> wrote:
>>> On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker 
>>> wrote:
>>>>
>>>> * establish support for fleshing out ideas before a DIP is 
>>>> even written
>>>>
>>>
>>> It's 2024. That should have been the principle a decade ago
>>>
>>> Remember how the so called 'discussions' about the 
>>> 'privateThis' concept always got heaped on. People just 
>>> wanted to shut it down rather that discuss it. 'Go write a 
>>> DIP' was the response...remember.
>>
>> The class vs module level of encapsulation was fleshed out a 
>> lot in the forums awhile back. I think it's fair to say most 
>> people where happy (or neutral) with the status quo, and were 
>> not convinced by the pro-class-level arguments.
>>
>> I also suspect those that did prefer class level private (I 
>> believe this is what Atila prefers), it's not high on their 
>> list of priorities.
>
> I like private as it is now. Especially because if anyone wants 
> it to be "class-private", they can do that anyway: write a 
> class per module like one has to in Java.
>
> My 2 centimes (cos I live in Switzerland) is that if you're 
> worried about too much code having access to your private 
> functions, your module is probably too large.

OpenD has already merged this into master anyway. So people can 
finally decided for themselves, rather than being told they don't 
need it and here's a workaround in case you do.

Btw. no DIP was required.

So if anyone wants an 'option' for "class-private", they can now 
do it in OpenD, and the this topic/debate is should be well and 
truly over. Just like const, @safe, ....etc... private(this) is 
there to use when your usecase requires as such. No effect on 
existing D code whatsoever.