C++ Logo

sg20

Advanced search

Re: [isocpp-sg20] Might is_*_type functions in reflection be confusing for users?

From: Xavier Bonaventura <xavibonaventura_at_[hidden]>
Date: Sat, 5 Jul 2025 20:11:43 +0200
Not yet, that part I'm still struggling on what does it mean if one of them
is not a type.

I was not so sure if
is_*_invocable_r_type and is_*_assignable_type should also be returning
false if any of the parameter is not a type.

My mental model was that if the input has only one input type then is a
clear answer. When it has more than one type then it is hard to say what
the answer means.

You hit the part that I was not so sure but I'm opened to suggestions.

Xavi


El ds., 5 de jul. 2025, 19:32, Ville Voutilainen <
ville.voutilainen_at_[hidden]> va escriure:

> On Sat, 5 Jul 2025 at 20:18, Xavier Bonaventura via SG20
> <sg20_at_[hidden]> wrote:
> >
> > Hi,
> >
> > I just wrote this paper about the topic and I would be interested on
> SG20 opinion
> > https://isocpp.org/files/papers/P3781R0.html
> > I stumbled across this when playing around with reflection and I had the
> feeling that it might be not intuitive when teaching.
> > The important part of the paper is the "Motivating example"
>
> Do you have a suggested teaching rationale for the difference between
>
> template <reflection_range R = initializer_list<info>>
> consteval bool is_constructible_type(info type, R&& type_args);
>
> and
>
> consteval bool is_assignable_type(info type_dst, info type_src);
>
> ?
>

Received on 2025-07-05 18:11:56