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@lists.isocpp.org> wrote:
On Mon, Nov 7, 2022 at 3:17 PM Smith, Jim via Std-Proposals
<std-proposals@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals