Provide reasonable default definition for is_contiguous

[user202729]

Another attempt at #4716 . Compiling base-test.cc takes around 10 seconds (both before and after), probably is fine. (not sure what else to measure.)

Instead of using contiguous_iterator, I just check whether .data() can be called on it; if it can be called, the container is likely contiguous. Opinion?

Some code assumes that if it's contiguous, .resize() exists, so it won't work for e.g. std::array even though that one is contiguous. But then back_insert_iterator doesn't work on std::array either.

Directly define a partial specialization of is_contiguous with typename = void leads to ambiguous overload errors, which is backwards incompatible if someone else special-case is_contiguous. See for example https://github.com/user202729/fmt/actions/runs/24015836992/job/70035092887

[vitaut]

Thanks for the PR! The idea makes sense but let's move SFINAE from a helper function and varargs hack to is_contiguous using void_t.

[afurm]

Requiring .resize(size_t{}) as a contiguity predicate seems unusual — .resize() is a mutating operation rather than a storage property. std::array has no .resize(), and std::string/std::vector can be used contiguously without resizing. Is this intentional, or could .resize() be removed from the check? What types would incorrectly match without it?

[vitaut]

I agree that we should drop resize check. Maybe a better check would be to see if iterator is a pointer?

[afurm]

Two technical concerns with this approach:

1. .resize() requirement is too strict

std::array, std::string_view, and std::span are all contiguous containers but lack .resize(). The current implementation will incorrectly classify them as non-contiguous. Consider splitting the check: one SFINAE expression for .data() + .size() + [] (the universal contiguous requirement), and a separate trait for .resize() availability for code paths that genuinely need it.

2. Varargs overload is unprincipled

is_contiguous_helper(...) as a fallback is a fragile SFINAE pattern. std::void_t is the idiomatic C++ standard approach for this — it is the technique used throughout the rest of the fmt codebase and is more maintainable.

Your suggestion to use void_t addresses both issues and would produce a cleaner diff overall.