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

[forkit]

On Wednesday, 8 June 2022 at 06:14:58 UTC, Ola Fosheim Grøstad 
wrote:
>
> There would be no downside if D was willing to take a breaking 
> change, but that is unlikely.

Huh?

private(this) ..(for example) is not a 'breaking' change. It's 
completly opt-in.

It provides a choice; Including a choice to just keep doing what 
you've always been doing.

The only argument against it, that would be worthwhile 
considering, is the cognitive effort in adapting to such a change.

private int myInt;
private(this) int myInt;

Not much cognitive effort required here ;-)

>
>> A module containing a large number of related, but potentially 
>> leaky abstractions, doesn't sound that great to me ;-)
>
> Then write a linter that  does what you want.
>

That's my point. It's sad that you even have consider the need to 
do this.
My C# compiler already does this for me. Even my C++ and Java 
compilers do it for me.

But not the D compiler.

>
> If nobody cared enough about this to write and use a linter 
> then that suggests that not enough people care about it enough 
> to warrant a language change.
>

That's cause, perhaps, to those whom it matters, they end up 
deciding not to use D.

What is their alternative course of action? Spend a year tring to 
get a DIP through that nobody in the D admin (Walter 
specifically) even wants.


>
> Just write the linter, if it gains traction then that is proof 
> that a language change should be considered.
>

The proof is already there - i.e. C++/Java/C# programmers, 
already use and rely upon this feature. Imagine if those 
lanaguages took it away.

"Sorry folks. We decided to take that feature that you've relied 
upon for so long, and dump it. Why don't you go write a linter 
instead."

I'm sure that would go over really well ;-)