On Thu, Nov 14, 2024 at 4:51 PM Jens Maurer via SG7 <sg7_at_[hidden]>
wrote:

>
> On 14/11/2024 16.48, Herb Sutter via SG7 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.
>
> There are no provisions in the reflection paper to apply
> access checks at point (B). It might be fairly hard to do
> so. Access checking in non-reflection code actually works
> on "names" (which might be considered point (A)), not
> on the actual access (point (B)). If a public function returns
> a pointer-to-member to private data, and that pointer-to-member
> is then used from the outside to access the private data, that's
> perfectly fine in current C++.
>
> The type, though, has to cooperate to construct that pointer to private
member, and give external access to it. `static_cast` lets me select a
particular overload of a name, I still can't select a private one.

I also realize this is not a small tweak to reflection, or a small ask.