Ville Voutilainen wrote:
> On Mon, 11 Nov 2024 at 13:23, Peter Dimov via SG7 <sg7_at_[hidden]>
> wrote:
>
> > I however do not know of any scenario in which a program would need to
> > do something with the set of accessible members. So having a way to
> > obtain that set doesn't seem useful to me.
>
> I do know of such cases. The generation of a qt_metacall implementation for a
> QObject-derivative class annotated with a Q_OBJECT macro works like that.
>
> You should perhaps consider the various use cases that have no need to do
> something with members that are inaccessible. When such use cases are
> written in terms of member queries that do not return inaccessible members,
> it's then categorically known that they perform no operations that bypass
> access. Which then means that they need no extra scrutiny to review that they
> do not break inaccessible invariants of things that protect invariants via access
> controls.

As I said, that's not how the language works. When you try to call a member
function (*), the call "sees" everything regardless of access. Once the function to
call is determined via overload resolution, _then_ it's checked for accessibility.

And that's exactly what P3451 proposes.

It's possible to envisage a C++ in which private members are really invisible
from the outside, even to sizeof, similar to how coroutines work now. But
that's not the C++ we have.

(*) Data members work the same way. https://godbolt.org/z/4v14EfK4o