Private, protected, and public provide control over inheritance of members,
which would not be possible by diligence alone (and the lack of "private"
would kill interoperability between various code sets by forcing all
developers to choose personally unique member variable names to allow
subclasses to exist without conflicting with base class should-be-private
member names), and the use case for design rule enforcement is enormous as
well. Otoh, the access-per-member use case seems rather esoteric (also
there are a lot of potential complications especially where inheritance and
templating become involved).

Const (and constexpr) allows the compiler to make various assumptions, and
allows code to exist that could not exist without it; allowing the
existence of a number of more complex language features especially where
temporary variables and references are concerned.

But more importantly, and to be blunt, things like private, protected,
public, const, override, those all enforce good, effective design patterns.
On the other hand, per-member access controls seem to enforce only bad
design patterns, where better organization of classes, improved
documentation, and testing are the typical good approach. To get to the
point where per-member access is necessary, mistakes would have had to have
been made, and C++ *tries* (sometimes failing, but it tries) to encourage
things that are not mistakes.

Jason

On Wed, Nov 9, 2022 at 9:58 AM Smith, Jim via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Thanks for the feedback!
>
> I understand what you're saying here because the ability to enforce these
> restriction isn't available in C++. We could use the same arguments if
> private, protected, public, and const were never implemented. These access
> specifiers were implemented to make controlling access to data an types
> easier than adding additional tests and comments.
>
>
> James S.
>
>
> ------- Original Message -------
> On Monday, November 7th, 2022 at 9:26 PM, Jason C via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
> I agree with the other Jason on this.
>
> Other appropriate design patterns and strategies can mitigate this issue,
> most notably *good documentation* and *unit testing*, among other things
> (such as other Jason's suggestion of splitting up the class). For example:
>
> /**
> * @postcondition data1 and data2 will not be modified.
> */
> void Foo::Method_2 () {
> }
>
> Having this documentation in a visible location will allow other
> developers to understand what should and shouldn't be done. Furthermore:
>
> void test_Foo_Method_2 () {
> Foo foo;
> auto data1 = foo.data1;
> auto data2 = foo.data2;
> foo.Method_2();
> FAIL_TEST_IF(foo.data1 != data1);
> FAIL_TEST_IF(foo.data2 != data2);
> }
>
> There, some fictitious unit testing framework is used to ensure that
> Method_2() behaves properly, where errors will be caught during testing
> presuming test case coverage is appropriate.
>
> A Different Jason
>
> On Mon, Nov 7, 2022 at 7:25 PM Jason McKesson via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Mon, Nov 7, 2022 at 3:17 PM Smith, Jim via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>> >
>> > Hi,
>> >
>> > Sometimes I'd like to hide data from a subset of class methods while
>> still allowing other methods to access them.
>>
>> I find this notion to be dubious. If a class is so big that, to ensure
>> the sanity of the class's state, it becomes necessary to give
>> individual member functions access to individual data members, then
>> that class has grown too big and needs to be split out into multiple
>> classes. The only downside is that it is slightly less convenient, as
>> the outer class has to explicitly expose the functions of the inner
>> class.
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>