> As you yourself said, I wouldn't tie this to TUs.

Sorry, I worded that badly. I don't want to tie this to TUs.
I meant "we should come up with rules that will result in TUs agreeing on
the interface of the class".
You are right to point out that it's not strictly the TUs that need to
agree but the class member functions. My bad.


Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> ezt írta
(időpont: 2026. ápr. 29., Sze 18:48):

> On Wednesday, 29 April 2026 02:51:20 Pacific Daylight Time Máté Ték via
> Std-
> Proposals wrote:
> > So what if we try to follow this principle as closely as possible?
> > - All TUs should agree on public/protected members -- we don't plan to
> > break this.
> > - TUs can be denied from knowing the private member methods of a class
> (on
> > a need-to-know basis)... -- we all seem to agree on this so far --
> > - ..., but those that need to know should all agree on the private
> > interface as well. (?)
>
> As you yourself said, I wouldn't tie this to TUs.
>
> I would say that all member functions of a class should agree on the
> private
> function and static data members, regardless of which TU they come from.
>
> This easily expands to protected: all members of this class and any
> derived
> ones must agree on the privates and protecteds.
>
> Failure to obey this rule would be ODR violation.
>
> All non-static data members must be visible to everyone, no exceptions.
>
> But see other email for another shortfall.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>