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
>