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.
