On Mon, 11 Nov 2024 at 14:04, Peter Dimov <pdimov_at_[hidden]> wrote:

> > 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.

It is how language works for everything else, but not for overload sets.
And even for overload sets, once the listing-query is for accessible
members, the
dependency to a private implementation detail can't be formed.

That's the point.