On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:
On Friday, 18 May 2018 at 16:24:24 UTC, Gheorghe Gabriel wrote:
On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:
On Friday, 18 May 2018 at 15:40:52 UTC, KingJo
class A {
private int x;
private(this) int y;
}
I agree that this looks a bit strange.
My initial proposal was "sealed" instead "private(this)" today.
Mmm.. that brings me back to the idea of sealed at the class
level again.
class A
{
private int x;
private(this) int y; // imagine if you have lots of private
variables.
// this could become pretty anoying -
and kinda redundant.
}
class A
{
private int x;
sealed int y; // again, what if you have lots of private
variables that
// that you really want sealed.
}
// Now. Back to the idea of sealed.
// abosolute consistency of your private variables.
// no redundancy.
// no some 'private', some 'sealed' confusion.
// no some 'private' (but really public) some 'private(this) ..
confusion.
//
sealed class A{
private int x;
private int y;
}
downside, is adding a new keyword, and getting agreement on
what that new keyword should be.
So I've come full circle again, and believe my idea is worth
further consideration.
If you have
sealed class A {
private {
// members
}
}
Then you can't use the defualt 'private' if you need it for a
specific member.
But if sealed is an access type of a member, 99% you will use
sealed insted private in a class, so it is not redundant.
class A {
sealed {
// members
}
private int friendMember;
}
And you use private keyword only if you need to access that
variable from a class/function/struct.. in the same module, like
a friend.
