On 17/11/2025 12:28, Giuseppe D'Angelo via Std-Proposals wrote:
> Il 14/11/25 15:38, Frederick Virchanza Gotham via Std-Proposals ha scritto:
>> Looking over the recent papers on reflection . . . I think this would
>> be done in reflection as follows:
>
> To be honest, with reflection in the language, we should take a step
> back and consider thinking about a policy here: will it still make sense
> to add more type traits to the standard library? If yes, what should be
> the bar for inclusion?
>
> What I'm trying to say is that queries that required compiler assistance
> (such as this one, "does this class have any `mutable` members?") are
> now entirely implementable in user code. Therefore there should be some
> justification as of why they should be added to the Standard Library.
>
> (Incomplete list,
> * query matches a language definition
> * query is difficult to write correctly, users might mess it up
> * query is common, would be better implemented as an intrinsic
> * ...)
>
> My 2 c,
>

Saying "the user can do this themselves with reflection" has perhaps
three major disadvantages. First, most C++ programmers are not going to
be confident with writing reflection code - at least, not for a /long/
time. Second, user-written reflection code is going to be much less
efficient than intrinsics or other compiler-specific implementations.
And thirdly, for things that can be useful to many people, you end up
with large numbers of incompatible solutions to the same problem.

I would rather say that with reflection, the bar to having such things
in the standard library is now somewhat lowered - we no longer have to
consider the feasibility or difficulty of implementing such features in
compilers as a portable reflection-based implementation can be written.
It makes field-testing and prototyping vastly easier and faster than
having to work with modified forks of compilers. And then if the new
feature is considered useful and popular, then compiler writers can, at
their own pace, provide built-ins or other more efficient implementations.

Of course we should still take care to identify reasons and use-cases
before adding such features to the standard library - no one wants the
standard (or the proposals mailing list) to be flooded with obscure
ideas just because they can be implemented easily. (I am not expressing
an opinion here about the potential usefulness of a "contains_mutable"
trait - the OP hasn't given a justification that I see as realistic, but
that does not mean real use-cases do not exist.)

David