I agree. The current model has access checks last. Private things are
visible, just not nameable. Otherwise we wouldn't have ambiguity issues.
For purposes of reflection, not all ill-formed should be the same. Many of
the rules are context dependent.
It's very possible to have a language that makes privacy even more private,
such that the public interface is unaffected by private details, and name
resolution doesn't consider such things at all. That's not C++.

Introspecting on Self is useful, so of course reflection should be able to
see protected and private members.

Just as a programmer can, looking at the source from above.

On Thu, Nov 14, 2024, 10:49 Herb Sutter <herb.sutter_at_[hidden]> wrote:

> Steve, I agree, but there’s a distinction some of us are making between
> (A) reflecting the metadata and (B) generating code to access data. I
> strongly agree (B) would break encapsulation and therefore should respect
> access and all other language rules by default (and I say so in P3437). My
> view has been that we should restrict (B) by default directly, not restrict
> (A) because it happens to indirectly make (B) harder as a side effect.
>
>
>
>
>
>
>
>
>
> *From:* SG7 <sg7-bounces_at_[hidden]> *On Behalf Of *Steve Downey
> via SG7
> *Sent:* Tuesday, November 12, 2024 8:52 PM
> *To:* sg7_at_[hidden]
> *Cc:* Steve Downey <sdowney_at_[hidden]>
> *Subject:* Re: [isocpp-sg7] SG7 late paper P3493R0 - Ruminations on
> reflection and access
>
>
>
> On the other hand we have about 40 years of saying no to all bypassing of
> access control.
>
> I don't see a new use case being mentioned, just a new technology for
> removing private and protected, without quite saying that we're getting rid
> of those.
>
>
>
> The desire to access inaccessible data is very old. But disallowing it was
> critical to C++ adoption.
>
>
>
> On Tue, Nov 12, 2024, 19:10 Peter Dimov via SG7 <sg7_at_[hidden]>
> wrote:
>
> Aurelien Cassagnes wrote:
> > Naively and very handwavely, if I dont want users of my types to be able
> to
> > reflect arbitrarily over it, what i want is a way to overload ^^
> operator for my
> > type and either assert(false) there to lock everything, or shape up some
> kind
> > of bespoke meta::info to be returned that fit my needs.
>
> As I said last time this came up, we've already been on this path before,
> with
> the unary operator&. People did what you wanted, overloaded op& and
> asserted, or returned something bespoke that I'm sure fit their needs, and
> as
> a result we had to add std::addressof which is operator&, except it
> bypasses
> those people.
>
>
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>
>