On Mon, 11 Nov 2024 at 16:16, Peter Dimov <pdimov_at_[hidden]> wrote:
>
> Ville Voutilainen wrote:
> > 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.
>
> I don't understand these statements. Overload resolution is performed
> before access checking.
>
> https://godbolt.org/z/x41erqKh9
>
> The overload set here contains both `f` functions, even though one is
> inaccessible; overload resolution is performed over this entire set, and
> then, after the best viable function is selected, its accessibility is checked.

And yet it doesn't give you the programmer the overload set, so that
you might actually
choose to depend on a private member.

An access-bypassing member listing operation does.

>Such trivial examples don't get us anywhere, because the same happens with
^^X::Nested.

Yeah, so listing what's under X shouldn't give you X::Nested, unless
you have access to it.

>Yes, you can iterate over the nested types, check whether identifier_of is
"Nested", get that reflection, and then cast away the access bits so that you
can splice it. I'd say that if you really invest all that effort, you
deserve to have
the type. Murphy, not Machiavelli, right?

I am working on this to protect against Murphy, and not Machiavelli.
If you actually bother reading the
examples in the beginning of my paper, you'll notice that C1/C2/C3/C4
are a very simple refactoring
apart from each other, and it doesn't take an actual Machiavelli to
half-accidentally depend on
one type having two fields with a double type instead of one field
with a rep type.

But when those fields are private in normal C++, that half-accidental
dependence never forms.
Whereas with the currently proposed reflection facilities in P2996, it
does form very easily, and you
need to do just the right kind of filtering to avoid it. And similar
dependencies on the cardinalities, types,
and names half-accidentally form for member types. And to get
protected access right, you need to seriously
know what you're doing, instead of forming those half-accidental dependencies.

I don't understand what you mean by "check identifier_of, get the
reflection, then cast away the access bits".
That doesn't describe P2996. And even with P3451, the dependency to
the types and cardinalities forms easily,
without any help from that proposal, because you do not need to splice
things to form such a dependency.
Splicing isn't the only dependency concern of this ilk. It's just a
special case of the general concern.