🚀 go-pugleaf

In <MATT.95Aug7100148@godzilla.EECS.Berkeley.EDU>, matt@godzilla.EECS.Berkeley.EDU (Matt Austern) writes:
>In article <404gjm$bhu@mujibur.inmind.com> mfinney@inmind.com writes:
>
>
>Maybe I'm missing something, but I don't see anything in the standard
>that's in need of correction. 
>
>Is there really any problem here that template specialization doesn't
>already solve?

When I wish to provide additional template operator definitions (non-member
functions) which map to specific functions, I have gotten template conflicts
because more than one template matches an instantiation.

In any case, those template definitions are clearly WRONG in general terms (as
many different examples show) and such a constraint should NOT be part of the
standard merely for the sake of "convenience" of the authors/users of STL.

Just because STL assumes a linear ordering over their iterators/collections does
NOT mean that the rest of the world can live with those constraints.

Michael Lee Finney