I think concepts allow this:

https://godbolt.org/z/fJLsv3

template <typename T>
auto foo(T const& in)
{
    if constexpr (requires { in.bar(10); })
        return in.bar(10);
    else return in.bar();
}

On Mon, Jul 15, 2019, 9:00 AM Matthew Woehlke via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Let's say I need to write some code like:
>
> template <typename T> auto foo(T const& in)
> {
> if constexpr (...magic...)
> return in.bar(some_argument);
> else
> return in.bar();
> }
>
> Specifically, I need to use the first form (`bar(...)`) iff that method
> is callable, and the second form (`bar()`; no arguments) otherwise.
>
> IIUC there *is* something that I can write for `...magic...` above...
> but from what I could find, it would be quite convoluted.
>
> What if I didn't have to? While thinking about this, it occurred to me
> that it might be useful to have the compiler attempt to compile code,
> with the ability to fall back to something else if it can't. Maybe
> something like:
>
> template <typename T> auto foo(T const& in)
> {
> try constexpr
> return in.bar(some_argument);
> catch constexpr
> return in.bar();
> }
>
> The compiler would attempt to compile the 'try' block, and if an error
> is encountered, would treat that block like an 'if constexpr' with a
> false condition and compile the 'catch' block instead. (For now I am not
> allowing specific types of failure to be "caught", but that could be
> room for future expansion.)
>
> Would something like this be interesting? (Am I missing a much easier
> way to accomplish this already?)
>
> Yes, reflection may make my specific case somewhat less obtuse, but I
> think there would still be value in the simplicity of such a construct,
> especially as it would "catch" many sorts of errors, some which may be
> more difficult to identify.
>
> --
> Matthew
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>