[Bug libstdc++/15910] can't compile self defined void distance(std::vector<T>, std::vector<T>)

["bangerth at dealii dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From bangerth at dealii dot org  2004-08-03 13:44 -------
So, how about this: we probably all agree that "it would be nice if it 
worked", but we're unsure whether we can make that change while staying 
in accordance with the standard. The usual course for this is to draft 
a DR to the language, in this case one in which one would add a sentence 
somewhere to the general bits of the library specification that function 
declarations may be rejected if the template arguments do not match 
their constraints. (Here, this means that std::distance may verify that 
its InputIterator template argument does really satisfy the requirements 
listed in table 72 for input iterators.) 
 
If such a DR has sufficient support that it sounds likely that it may  
eventually be part of the standard, then implementing it in libstdc++ 
is a reasonable thing. 
 
Note that a clause like this in the standard would be very much in line 
with recent standardization work of constraints on template parameters 
in general (I'm sure Gaby has a lot to say about this) and would be 
an application of these constraints within the library. It is also 
worth mentioning that it would be strictly compatible: whatever is 
valid now will be valid in the future, though a number of programs 
(such as the one in this PR) were invalid before and will be valid 
afterwards. [1] 
 
W. 
 
[1] What does make me nervous, though, is the following: if the standard 
_allows_ us to check constraints on template parameters, and we do 
so, then the program in this PR will become valid. However, it will not 
necessarily become portable: other compiler libraries may not follow 
this "allows to" clause, and this program will not be compilable there. 
This is why I would much rather prefer if the standard actually prescribed 
the correct signature of std::distance, as this is the only way to make 
sure that programs remain compatible. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910