[alg.fold] Spelling the actual`ranges::fold_meow`'s return type in function signature?

[hewillk]

For people like me who have been dealing with decltype() and type traits for a long time, the return type of ranges::fold_meow is still daunting.
I had to go back and forth a few times to the various overloads to really understand what the actual return type of these overloads was, because they all were specified as auto or delctype(fold_moew(...)), which is very unintuitive, see [alg.fold] for details.
I suspect that this way of defining return types may be extremely unfriendly to non-expert users, and it would be nice if we could spell the correct concrete type directly in the function signature, for example:

template<input_iterator I, sentinel_for<I> S, class T = iter_value_t<I>,
         indirectly-binary-left-foldable<T, I> F>
constexpr decay_t<invoke_result_t<F&, iter_reference_t<I>, T>> 
ranges::fold_left(I first, S last, T init, F f);

I believe this is editorial, but not sure if there are any other implicit issue with doing this.
But what is certain is that the current way of spelling the return type is indeed inconvenient.

[jensmaurer]

An "auto" return type is not SFINAE-friendly, but an explicit return type is. So, this is not obviously an editorial change.

[hewillk]

An "auto" return type is not SFINAE-friendly, but an explicit return type is. So, this is not obviously an editorial change.

I know, but the function's constraints already accommodate the validity of the explicit return type, so they should be equivalent?

[jensmaurer]

the function's constraints already accommodate the validity of the explicit return type

Ok; if someone is familiar with those concepts and can vouch for those guaranteeing a value return type.

@jwakely , any opinion here?

[jwakely]

I'd prefer to do this via an LWG issue, even though it means more work for me!

[frederick-vs-ja]

An "auto" return type is not SFINAE-friendly, but an explicit return type is. So, this is not obviously an editorial change.

I know, but the function's constraints already accommodate the validity of the explicit return type, so they should be equivalent?

Ideally, they should be. But I think there're some cases where F is not well constrained, and thus when using ranges::fold_meow in an unevaluated operand, explicitly specifying the return type can avoid instantiation of the function body and make a currently ill-formed program well-formed.

An LWG issue seems necessary to me.

[hewillk]

This is LWG 4095.
I'm really not sure if it ends up being NAD (which would be sad news).

[frederick-vs-ja]

But I think there're some cases where F is not well constrained, and thus when using ranges::fold_meow in an unevaluated operand, explicitly specifying the return type can avoid instantiation of the function body and make a currently ill-formed program well-formed.

Do such cases fall into the "sastifying-but-not-modeling" area? If so, such uses are IFNDR, and explicitly specifying return types doesn't seem to change the status.