Date: Tue, 12 Nov 2024 20:51:56 -0500
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
>
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
>
Received on 2024-11-13 01:52:12