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] <mailto: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] <mailto:SG7_at_[hidden]> 
https://lists.isocpp.org/mailman/listinfo.cgi/sg7