> With reflection, won't tests be able to break encapsulation whenever they want?

I hope not. I didn't think that was the point. I feel that this has to be done in a more structured way.

> It's not clear to me why this hypothetical interface class needs to be able to access the private data of some unbounded set of `bar` and `foo` "like objects".

Not "private"... better described as "restricted".

I have a particular example that comes to mind on a project I worked on for a peripheral IO interface.
Different types of "IO" would can be instantiated depending on the capabilities of the physical hardware, and I want the representation of those IOs to be registered in a central registration object where they can also send events to.
But this central registration object also has user facing API to register event recipients, query properties, setup options etc...
The IO controllers are multiple unknown, it can be extended via a plugin system (depends on hardware) but they are all "IO"s, the user API is code to be written by the user.

I want my IOs to be able to register and send events and advertise capabilities, but not set properties of other devices or register callbacks, and I want my user to register callbacks and set properties but not register IO end points.

Granted it is a different proposal than just make it outright friends, but still an evolution in the access control space.


________________________________
From: Std-Discussion <std-discussion-bounces_at_[hidden]> on behalf of Jason McKesson via Std-Discussion <std-discussion_at_[hidden]>
Sent: Saturday, June 21, 2025 8:01:03 PM
To: std-discussion_at_[hidden] <std-discussion_at_[hidden]>
Cc: Jason McKesson <jmckesson_at_[hidden]>
Subject: Re: [std-discussion] A Idea: Friend with Conditions

On Sat, Jun 21, 2025 at 11:46 AM Tiago Freire <tmiguelf_at_[hidden]> wrote:
>
> I'm not convinced about the particular syntax.
>
> But let's say we have the following:
>
> public(T, is_derived_from<T, unit_test>):
>
> now I don't need compromise the class in order to evaluate internal states in unit tests.

With reflection, won't tests be able to break encapsulation whenever they want?

> let's say that you have an interface class that interacts with "bar" like objects and "foo" type objects but I don't want "foo" to interact with "bar" interfaces and I don't want "bar" to interact with "foo" interfaces... this would be very useful.

It's not clear to me why this hypothetical interface class needs to be
able to access the private data of some unbounded set of `bar` and
`foo` "like objects".
--
Std-Discussion mailing list
Std-Discussion_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion