Confusion regarding result_for

[panic-sell]

Confusion regarding result_for

[pdimov]

You can forward-declare result_for. See for example how it's done in Variant2: https://github.com/boostorg/variant2/blob/9e4234bfd5688c0272b641954ab2f23f8ce9c613/include/boost/variant2/variant.hpp#L2430-L2530

[panic-sell]

Thanks. IIUC, by forward declaring all Boost.Json names and only implementing tag_invoke() in terms of those forward declarations, we can avoid making our custom types depend on Boost.Json

That said, I notice examples in https://www.boost.org/doc/libs/1_83_0/libs/json/doc/html/json/conversion/non_throwing_conversions.html use result_for (despite depending on Boost.Json per calls to jv.get_array()). Is the recommendation to prefer result_for over result even when code does depend on Boost.Json? If so, why?

[pdimov]

The same example does use result directly inside the function; result_for in the signature is probably only used to match the declaration of tag_invoke given above.

I can't think of any reason to prefer result_for if you don't mind including JSON (or System) headers.

[grisumbras]

Yes, there's absolutely no reason to prefer result_for over result If you're including JSON headers. As @pdimov suggested, the linked example uses result_for in the return type to match the signature, in order to be less confusing for the user.

[panic-sell]

Awesome, thanks for the explanation.