Hmm, I was kinda hoping that the compiler could generate a synthetic type
for each concept that fulfills the constraints (and nothing else...) and
evaluate the expressions based upon those generated types. (I can, however,
see that OR:ed concepts will make things messy.. )

// Robin

On Mon, Sep 2, 2024, 20:56 Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Mon, Sep 2, 2024 at 2:35 PM Robin Savonen Söderholm via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
> >
> > Hi!
> >
> > I've come into situations with concepts where I'd like to do something
> along the lines of this:
> > ```c++
> >
> > template <typename T>
> > concept has_foo = requires(T&& t, int i /* and so on...*/ ) { t.foo1(i);
> /*and maybe more functions*/};
> >
> > template <typename T>
> > concept fooable = requires(T&& t, has_foo auto&& f) { t.do_foo_stuff(f);
> };
> >
> > ```
> > , but I can't as far as I know. So as far as I can tell, I have 2
> options here: add a second template parameter to "fooable" or create a
> dummy class that fullfills "has_foo". However, none of these options are
> always optimal. If we consider the following example instead:
> > ```c++
> > template <typename T>
> > concept has_foo = requires(T&& t, int i, float f) { t.foo(i);
> t.foo_bar(i, f); };
> >
> > template <typename T>
> > concept fooable = requires(T&& t, has_foo auto&& f) { t.do_foo_stuff(f);
> };
> >
> > template <fooable TF>
> > class handler_for_fooable {
> > TF f_;
> > public:
> > void bar(auto&& f) requires(requires {f_.do_foo_stuff(f); }) {
> > // do stuff.
> > f_.do_foo_stuff(f);
> > }
> > };
> > ```
> > In this case, we can discuss the varying problems with each solution.
> > If we add another template parameter to "fooable", we must know at
> instantiation of handler_for_fooable what type will be used in bar().
> Furthermore, we must either require that the second parameter to "has_foo"
> is a "fooable" which may be too restrictive or, we skip the "has_foo"
> requirement and risk having to look at a very large wall of text to figure
> out if the "has_foo"-type or the "fooable" is wrong. If we instead add
> dummy parameter that fullfills "has_foo", we remove the earlier problems
> mentioned, but instead get a few new ones: first we have to do double
> bookkeeping on the interfaces the concepts describe, secondary the API
> description for a user of the library will look fishy and someone may
> accidentially use the dummy type in their function signature or what not,
> and thirdly the dummy type may be incorrect (what about copy/move
> construction/assignment for example?)
> >
> > I would like to have a way to express "given some type that fulfills the
> constraint X, type T shall fulfil Y."
> > I understand that this can be a very expensive feature, but I would like
> to at least discuss the idea. Or is there a paper for something similar?
> >
> > // Robin
>
> The problem is that constraints are not applied on the basis of
> hypothetical types. They're applied on the basis of *actual* types.
> The concept `fooable` fundamentally represents a relationship between
> two unknown types. Not "one concrete type and some unknown family of
> types fulfilling some constraint", but "two concrete types".
>
> When you provide template parameters to a constraint, the system has
> to check, at that point, whether the given parameters fulfill the
> requirements of that constraint. So it has to substitute in actual
> types and check that the expressions are valid and result in what the
> constraints say they should result in.
>
> So, how would `t.do_foo_stuff(f)` work? The type of `f` is not known.
> So how could the system tell if `t.do_foo_stuff(f)` would be a legal
> expression? How would it do overload resolution if it doesn't have a
> concrete type to use that overload resolution on? How would template
> argument substitution work in that function call?
>
> I get the idea you're trying to do, but it simply isn't reasonable.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>