One potential solution appears to be patching has_const_begin_end and has_mutable_begin_end as follows ...

template <typename T>
struct has_const_begin_end<
    T,
    void_t<
        decltype(detail::range_begin(std::declval<const remove_cvref_t<T>&>())),
        decltype(detail::range_end(std::declval<const remove_cvref_t<T>&>())),
        decltype(detail::range_begin(std::declval<const remove_cvref_t<T>&>()) != detail::range_end(std::declval<const remove_cvref_t<T>&>()))>> // Added
    : std::true_type {};

template <typename T>
struct has_mutable_begin_end<
    T, void_t<decltype(detail::range_begin(std::declval<T>())),
              decltype(detail::range_end(std::declval<T>())),
              decltype(detail::range_begin(std::declval<T>()) != detail::range_end(std::declval<T>())), // Added
              enable_if_t<std::is_copy_constructible<T>::value>>> 
    : std::true_type {};

FMT_DEPRECATED_OSTREAM has been removed so this conflict won't happen on the current version. You can format objects via ostream as follows:

  fmt::print("{}\n", fmt::streamed(m));

In this case Eigen providing broken begin / end doesn't matter.

@vitaut I think that FMT_DEPRECATED_OSTREAM is a bit of a red herring in this case. Even if this is removed and a custom fomatter is provided, the issue is still present.

See the updated godbolt here for an example: https://godbolt.org/z/xbETKd5h1

I think that is_range is incorrectly returning that Eigen::Matrix3d is a range when it in fact not.

E.g. https://godbolt.org/z/xbETKd5h1

I think you are right and we should improve the begin/end check. Could you submit a PR with your proposed fix?

I hit the same issue with Eigen years ago, they haven't done a new release in years.

I came across a similar problem, but with a different compiler error: https://godbolt.org/z/PTPzGjY1P

It seems to be the same issue, where the is_range check is "true" for this type even when there's an explicit formatter defined for it. My example only uses fmt and shows an ambiguous template instantiation error. If it's a different problem, I can open a new issue. This did become more problematic for us as we use fmt::join() pretty heavily, and the new requirement of including the ranges.h header makes this show up everywhere for us.

@jdrouhard, if you want to override the standard range formatter you also have to opt out of it being formatted as a range or use an adapter type. is_range cannot do it for you.

Yeah, that's not what we're trying to do.

We have some types with begin() and end() but we specifically don't want them to be formatted as ranges. Including fmt/ranges.h breaks a lot of our codebase because there is now an ambiguous template instantiation: the "detected" range formatter as well as our custom formatter that we prefer to use (either via format_as() or by specializing the formatter type - both cause ambiguous instantiations).

See the godbolt link above which shows what I'm talking about. Commenting out the ranges.h header lets it compile, but we lose fmt::join in trunk. It works currently in 10.2.1 because fmt::join() isn't in that header and we don't really use anything from the ranges.h header otherwise.

It seems that the range formatter that simply detects whether a type should be formatted as a range should be disabled if the type has an explicit format_as() or formatter<> specialization. Ambiguous template instantiations that cause code to not compile isn't great :)

Fixed in #3964 (thanks to @Arghnews).