https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71771
Casey Carter <Casey at Carter dot net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |Casey at Carter dot net
--- Comment #5 from Casey Carter <Casey at Carter dot net> ---
The result of defending against one unconstrained template by adding another
unconstrained template is that we now have two problems instead of one ;)
Implementations of the Ranges TS (e.g., range-v3) now have to workaround the
unconstrained operator- templates in the standard library.
I would argue that your example program demonstrates that libstdc++ is not
conforming *with* the single-type overloads, because on a conforming
implementation m - m and r - r would result in calls to greedy::operator-.
As to the separate question of what behavior that program *should* have, I
would not have a problem (from my viewpoint in the "every template is
constrained" world of range-v3 / Ranges TS) with single-type *constrained*
overloads a la libstdc++'s operator- for move_iterator instead of the
unconstrained operator- for reverse_iterator. It's still a problem that
greedy::operator- thinks it can subtract reverse_iterator<anything>, but at
least the standard library wouldn't be making things worse.
If you think that defending against unconstrained templates is important, then
we should open a library issue to standardize that behavior. From my experience
with range-v3, fighting unconstrained templates seems to generally be a losing
battle; I think we'd be better off simply forbidding them than trying to
specify our way around them.
