[Bug c++/40497] New: invalid std::next / std::prev declaration

[Bug c++/40497] New: invalid std::next / std::prev declaration

[e28773 at bsnow dot net]

Hello

using gcc 4.4 with -std=c++0x and libstdc++ off the trunk, I get several errors
on old code.
When calling next(X) with a user defined class type X, adl does not seem to
prefer the next function defined in the namespace of X.

Testcase from boost:
http://www.boost.org/development/tests/trunk/developer/output/Sandia-gcc-boost-bin-v2-libs-fusion-test-cons-test-gcc-4-4-0_gnu++0x-debug-sequence.html

changing the types of the second arguments of std::next/std::prev from typename
iterator_traits<Iterator>::difference_type to typename
Iterator::difference_type (as proposed in 24.4p4) does work. I assume this is a
bug.


-- 
           Summary: invalid std::next / std::prev declaration
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: e28773 at bsnow dot net


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2009-06-20 10:13 -------
We need preprocessed source as a testcase.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[e28773 at bsnow dot net]

------- Comment #2 from e28773 at bsnow dot net  2009-06-20 12:30 -------
Created an attachment (id=18029)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18029&action=view)
test-case


-- 


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[e28773 at bsnow dot net]

------- Comment #3 from e28773 at bsnow dot net  2009-06-20 12:31 -------
Created an attachment (id=18030)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18030&action=view)
testcase - ii


-- 


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[e28773 at bsnow dot net]

------- Comment #4 from e28773 at bsnow dot net  2009-06-20 12:32 -------
(From update of attachment 18029)
namespace X
{
        class C
        {
        };

        template<class T>void next(T)
        {
        }
}
using namespace X;

#include <string>
using namespace std;

int main()
{
        C c;
        next(c);
}


-- 


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[e28773 at bsnow dot net]

------- Comment #5 from e28773 at bsnow dot net  2009-06-20 12:33 -------
here we go ;)

I forgot a ';' in line 5 of the main.cpp-file


-- 


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[rguenth at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1645 bytes --]



------- Comment #6 from rguenth at gcc dot gnu dot org  2009-06-20 13:04 -------
Confirmed (testcase from comment #4 with -std=c++0x).

It looks like a failure to honor SFINAE?

$ g++-4.4 -S -std=c++0x t.C
In file included from /usr/include/c++/4.4/bits/stl_algobase.h:67,
                 from /usr/include/c++/4.4/bits/char_traits.h:41,
                 from /usr/include/c++/4.4/string:42,
                 from t.C:13:
/usr/include/c++/4.4/bits/stl_iterator_base_types.h: In instantiation of
‘std::iterator_traits<X::C>’:
t.C:19:   instantiated from here
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:127: error: no type named
‘iterator_category’ in ‘class X::C’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:128: error: no type named
‘value_type’ in ‘class X::C’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:129: error: no type named
‘difference_type’ in ‘class X::C’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:130: error: no type named
‘pointer’ in ‘class X::C’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:131: error: no type named
‘reference’ in ‘class X::C’


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |rejects-valid
   Last reconfirmed|0000-00-00 00:00:00         |2009-06-20 13:04:18
               date|                            |


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[paolo dot carlini at oracle dot com]

------- Comment #7 from paolo dot carlini at oracle dot com  2009-06-20 21:35 -------
Ok, implementing the letter of the current draft (n2857) seems trivial to do
(note: at some point, in particular for extensive changes, we will stop doing
that in the release branch).


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
                   |dot org                     |dot com
             Status|NEW                         |ASSIGNED
   Target Milestone|---                         |4.4.1


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[paolo at gcc dot gnu dot org]

------- Comment #8 from paolo at gcc dot gnu dot org  2009-06-20 22:27 -------
Subject: Bug 40497

Author: paolo
Date: Sat Jun 20 22:27:04 2009
New Revision: 148751

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148751
Log:
2009-06-20  Paolo Carlini  <paolo.carlini@oracle.com>

        PR libstdc++/40497
        * include/bits/stl_iterator_base_funcs.h (next, prev): Fix the
        signature per the current C++1x draft (N2857).
        * testsuite/24_iterators/operations/40497.cc: Add.

Added:
    trunk/libstdc++-v3/testsuite/24_iterators/operations/40497.cc
Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/bits/stl_iterator_base_funcs.h


-- 


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[paolo at gcc dot gnu dot org]

------- Comment #9 from paolo at gcc dot gnu dot org  2009-06-20 22:27 -------
Subject: Bug 40497

Author: paolo
Date: Sat Jun 20 22:27:21 2009
New Revision: 148752

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148752
Log:
2009-06-20  Paolo Carlini  <paolo.carlini@oracle.com>

        PR libstdc++/40497
        * include/bits/stl_iterator_base_funcs.h (next, prev): Fix the
        signature per the current C++1x draft (N2857).
        * testsuite/24_iterators/operations/40497.cc: Add.

Added:
   
branches/gcc-4_4-branch/libstdc++-v3/testsuite/24_iterators/operations/40497.cc
Modified:
    branches/gcc-4_4-branch/libstdc++-v3/ChangeLog
    branches/gcc-4_4-branch/libstdc++-v3/include/bits/stl_iterator_base_funcs.h


-- 


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[paolo dot carlini at oracle dot com]

------- Comment #10 from paolo dot carlini at oracle dot com  2009-06-20 22:29 -------
Fixed for 4.4.1.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[e28773 at bsnow dot net]

------- Comment #11 from e28773 at bsnow dot net  2009-06-20 23:21 -------
(In reply to comment #10)
> Fixed for 4.4.1.
> 
After all, this is still a bug of ADL/SFINAE? Even if the declaration of
next/prev does not match with the one proposed in the current draft, the right
function (that is in the namespace of the argument) should still be chosen?!


-- 

e28773 at bsnow dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


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

[Bug c++/40497] invalid std::next / std::prev declaration

[paolo dot carlini at oracle dot com]

------- Comment #12 from paolo dot carlini at oracle dot com  2009-06-21 01:03 -------
Yes, either that or wontfix until we have concepts as a library issue.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
                   |dot com                     |dot org
             Status|REOPENED                    |NEW
          Component|libstdc++                   |c++


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

[Bug c++/40497] invalid std::next / std::prev declaration

[paolo dot carlini at oracle dot com]

------- Comment #13 from paolo dot carlini at oracle dot com  2009-06-21 01:05 -------
See: http://gcc.gnu.org/ml/libstdc++/2009-06/msg00057.html


-- 


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

[Bug c++/40497] invalid std::next / std::prev declaration

[rguenth at gcc dot gnu dot org]

------- Comment #14 from rguenth at gcc dot gnu dot org  2009-06-21 10:38 -------
Testcase w/o std=c++0x:

template <typename I> struct T { typedef typename I::d d; };
template <typename I> I next(I __x, typename T<I>::d __n = 1);
namespace X
{
  class C { };
  template<class T> void next(T) { }
}
int main()
{
  X::C c;
  next(c);
}

but EDG rejects this also:

t.C(1): error: class "X::C" has no member "d"
  template <typename I> struct T { typedef typename I::d d; };
                                                       ^
          detected during instantiation of class "T<I> [with I=X::C]" at line
11

t.C(11): error: more than one instance of function template "next" matches the
argument list:
            function template "void X::next(T)"
            function template "I next(I, T<I>::d)"
            argument types are: (X::C)
    next(c);
    ^

I'm not sure SFINAE applies here as the substitution T<I> succeeds.

With the 'typename' removed in the decl for next we get

t.C(2): error: nontype "T<I>::d [with I=I]" is not a type name
  template <typename I> I next(I __x, T<I>::d __n = 1);
                                      ^

t.C(11): error: more than one instance of function template "next" matches the
argument list:
            function template "void X::next(T)"
            function template "I next(I, <error-type>)"
            argument types are: (X::C)
    next(c);
    ^

with

template <typename I> I next(typename T<I>::d __n);

we finally get SFINAE and X::next is chosen.

The issue here seems to be that the default value for the argument somehow
gets in the way and so the 2nd argument isn't checked properly?

So an implementation workaround would be to use overloading for the
default argument case like

template <typename I> I next(I __x, typename T<I>::d __n);
template <typename I> I next(I __x);

with the first arg obfuscated so that SFINAE applies,
typename iterator_traits<_InputIterator>::_InputIterator

or something like this?


-- 


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

[Bug c++/40497] invalid std::next / std::prev declaration

[rguenth at gcc dot gnu dot org]

------- Comment #15 from rguenth at gcc dot gnu dot org  2009-06-21 10:41 -------
Bah, of course the template param isn't forwarded as a type in iterator_traits
nor is it required as a type for iterator implementations.


-- 


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

[Bug c++/40497] invalid std::next / std::prev declaration

[paolo dot carlini at oracle dot com]

------- Comment #16 from paolo dot carlini at oracle dot com  2009-06-21 11:08 -------
This is interesting and indeed, I'm not at all sure it's a C++ bug, but I seem
to remember an open PR about SFINAE vs defaults, we should check. As regards
the library side, anyway, I'm against putting in place ugly workarounds, do not
really make sense in this case. These next/prev are supposed to be very
straightforward facilities, straightforward to implement when concepts are
available. If it turns out they just make more difficult testing the other
C++0x bits we already have in place we'll simply remove the code for now: let's
make sure we don't ship 4.4.1 with this issue open.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paolo dot carlini at oracle
                   |                            |dot com


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

[Bug c++/40497] invalid std::next / std::prev declaration

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.1                       |4.4.2


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

[Bug c++/40497] invalid std::next / std::prev declaration

[paolo dot carlini at oracle dot com]

------- Comment #17 from paolo dot carlini at oracle dot com  2009-07-26 14:46 -------
Maybe Jason can help confirming that we don't have a C++ issue here?!? In that
case, however, since Concepts are gone, I think we should probably file a
library DR or raise the issue vs the rolled-back Draft. Opinions about that?

Anyway, something consistent with the C++03 advance, would be probably ok, in a
non-Concepts context:

  template<typename _InputIterator, typename _Distance>
    inline _InputIterator 
    next(_InputIterator __x, _Distance __n = 1)
    {
      std::advance(__x, __n);
      return __x;
    }

I'm thinking of changing the libstdc++ code like this, for now, instead of
removing it completely to be safe.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu dot org


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

[Bug c++/40497] invalid std::next / std::prev declaration

[paolo dot carlini at oracle dot com]

------- Comment #18 from paolo dot carlini at oracle dot com  2009-07-26 15:45 -------
Never mind the draft next, of course doesn't work, grunt (_Distance?)


-- 


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

[Bug c++/40497] invalid std::next / std::prev declaration

[jason at gcc dot gnu dot org]

------- Comment #19 from jason at gcc dot gnu dot org  2009-07-27 01:08 -------
That does seem like a SFINAE bug.


-- 


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

[Bug c++/40497] invalid std::next / std::prev declaration

[jason at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 755 bytes --]



------- Comment #20 from jason at gcc dot gnu dot org  2009-07-27 05:46 -------
Actually, no.  It seems that T<X::C> being invalid doesn't result in a SFINAE
situation.

14.9.2/8:
  Only invalid types and expressions in the immediate context of the function
type and its template parameter types can result in a deduction failure. [
Note: The evaluation of the substituted types and expressions can result in
side effects such as the instantiation of class template specializations and/or
function template specializations, the generation of implicitly-defined
functions, etc. Such side effects are not in the “immediate context” and can
result in the program being ill-formed. — end note ]


-- 


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[paolo dot carlini at oracle dot com]

------- Comment #21 from paolo dot carlini at oracle dot com  2009-07-27 09:34 -------
Thanks Jason. I'm tentatively recategorizing as libstdc++, then. In general,
I'm not at all sure what we should do about it, however, now that Concepts are
gone. I don't think we can hope to avoid, here and elsewhere, all the typical
problems caused by unconstrained templates. Certainly, having the two separate
overloads:

  template<typename InputIterator, typename Distance>
    InputIterator next(InputIterator, Distance);

  template<typename InputIterator>
    InputIterator next(InputIterator);

would lead to cleaner error messages in case of ambiguities, but I'm not sure
we can in general achieve much more than this.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |libstdc++


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.2                       |4.4.3


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[paolo dot carlini at oracle dot com]

------- Comment #22 from paolo dot carlini at oracle dot com  2009-12-16 16:15 -------
Jon, what's your opinion about this one, now that concepts are gone? Frankly, I
don't think we can do much to avoid this type of problem.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jason at gcc dot gnu dot org|


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[jwakely dot gcc at gmail dot com]

------- Comment #23 from jwakely dot gcc at gmail dot com  2009-12-17 11:55 -------
I can't see any 100% reliable way to prevent this problem, because the
catch-all specialisation of iterator_traits can be instantiated with
non-iterator types.

We could try tricks like this to restrict std::next to things that look like
iterators:

// deduction fails if _Iter doesn't meet InputIterator requirements
template<typename _Iter,
  typename _Sfinae1 = decltype(*std::declval<_Iter&>()),
  typename _Sfinae2 = decltype(++std::declval<_Iter&>()),
  typename _Sfinae3 = decltype(std::declval<_Iter&>()++),
  typename _Sfinae4 = decltype(*std::declval<_Iter&>()++),
  typename _Sfinae5 = decltype(std::declval<_Iter&>()==std::declval<_Iter&>())
  >
  typename iterator_traits<_Iter>::difference_type
  __safe_iterator_diff_type(_Iter);

template<typename _InputIterator>
  inline _InputIterator
  next(_InputIterator __x, decltype(__safe_iterator_diff_type(__x)) __n = 1)
  {
    std::advance(__x, __n);
    return __x;
  }

But that will still fail for types that have an iterator-like interface.  Then
again, I think such types would be detected as iterators even with concepts.


-- 


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[jwakely dot gcc at gmail dot com]

------- Comment #24 from jwakely dot gcc at gmail dot com  2009-12-17 12:01 -------
Although that breaks if any of the iterator-like operators exists but is not
accessible - I think concepts would have worked in that case, but I'm not sure


-- 


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[paolo dot carlini at oracle dot com]

------- Comment #25 from paolo dot carlini at oracle dot com  2009-12-17 12:07 -------
Interesting trick, really, the power of extended SFINAE ;) I think we should
keep that in mind, for the DO THE RIGHT THING clause of the containers too, for
example (some time ago Howard told me that in his Metrowerks implementation, it
is *much* better than the minimum requirements of the standard, it almost
always actually does the right thing ;) but he did that a lot of time ago, it's
probably just a jungle of enable_ifs + "something"). So... What do you think,
shall we have an "__is_iterator" trait and use it where it's useful? For
post-4.5.0, in any case...


-- 


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[paolo dot carlini at oracle dot com]

------- Comment #26 from paolo dot carlini at oracle dot com  2009-12-17 12:11 -------
Yeah, the usual accessibility issue: in Santa Cruz I discussed that briefly
with Doug, he pretended to convince people that with extended SFINAE you can
implement trivially *any* introspection trait, then somebody (me too) pointed
out the accessibility issue and he said "bah, I don't care, accessibility is
"broken" n  C++ anyway" ;)


-- 


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[jwakely dot gcc at gmail dot com]

------- Comment #27 from jwakely dot gcc at gmail dot com  2009-12-17 12:23 -------
ha!

std::next would want is_input_iterator and std::prev would ideally want
is_bidi_iterator, so maybe more than one trait


-- 


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[paolo dot carlini at oracle dot com]

------- Comment #28 from paolo dot carlini at oracle dot com  2009-12-17 12:25 -------
Actually, details, std::next now wants _ForwardIterator, don't ask me to lookup
the DR ;)


-- 


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[redi at gcc dot gnu dot org]

------- Comment #29 from redi at gcc dot gnu dot org  2009-12-18 00:15 -------
I think it might be worth opening an issue about these functions, it's far too
easy for them to cause problems and make the names "next" and "prev" unusable
for user functions:

// simplified version of <iterator> and <string>
namespace std {
template<class Iterator> struct iterator_traits {
typedef typename Iterator::difference_type difference_type;
typedef typename Iterator::value_type value_type;
typedef typename Iterator::pointer pointer;
typedef typename Iterator::reference reference;
typedef typename Iterator::iterator_category iterator_category;
};

template <class InputIterator>
InputIterator next(InputIterator x,
typename std::iterator_traits<InputIterator>::difference_type n = 1);

struct string { };
}


// user code

struct C { };
void next(C, std::string) { }

int main()
{
  C c;
  next(c, std::string());
}

For a user-declared function with an argument of type from namespace std, ADL
finds std::next and we get the same error due to instantiating
iterator_traits<C>


-- 


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[paolo dot carlini at oracle dot com]

------- Comment #30 from paolo dot carlini at oracle dot com  2009-12-18 00:58 -------
I agree. In general, however, I'm not sure how general the issue is, now that
concepts are gone. For example, consider the case of the various classification
functions (from C99): you can still find a PR filed by Howard a lot of time
ago, where he complained that we weren't restricting the templates and that
could cause problems with some user functions, which arguably were not supposed
to conflict with those C99 extensions (in strict C++03 mode). Thus we added the
enable_ifs. Now, if you look at the WP, those use just unrestricted templates
and indeed user functions can be affected, similarly to next and prev. Outside
the few places in the WP where the famous "does not participate to overload
resolution" is used, there are in my opinion far too many grey areas where,
missing real concepts, some sort of restriction is supposed to be enforced for
QoI to counteract the obnoxious ADL problems, without however stating that
clearly anywhere: if you talk to Howard he more or less assumes by default,
irrespective of the actual WP, that all the templates in the library are
somewhat restricted via enable_ifs, for instance all the mathematical functions
for arithmetic types only, etc, otherwise the users can complain *rightfully*
about ADL-caused problems at any time. Well, I'm not sure that is correct, I
don't think the library has necessarily to battle this futile war against ADL
;) with tons of enable_ifs even where the standard definitely does not say that
explicitly. To finish, a remark is in order about the *tough* cases, like
*iterator* exactly, where you can't really replace concepts, via SFINAE & co,
for the reasons which we just discussed. What should the standard say? Should
it try to do better than C++03 now that we know about enable_if and extended
SFINAE, etc, or not, in the famous futile war with ADL?


-- 


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.3                       |4.4.4


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.4                       |4.4.5


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[redi at gcc dot gnu dot org]

------- Comment #31 from redi at gcc dot gnu dot org  2010-05-27 10:21 -------
(In reply to comment #23)
> I can't see any 100% reliable way to prevent this problem, because the
> catch-all specialisation of iterator_traits can be instantiated with
> non-iterator types.

I was under the impression that the default specialisation of iterator_traits
was meant to be catch-all, but Alisdair Meredith described his implementation
and I realised that the definition in [iterator.traits]/2 applies to type
"Iterator" and [iterator.traits]/1 says "if Iterator is the type of an
iterator"

So now I believe that we can (and should) restrict that specialisation to types
that really are iterators. If iterator_traits<NotAnIterator>::difference_type
doesn't exist then SFINAE will apply and std::next/std::prev will not cause
invalid instantiations.


-- 


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[paolo dot carlini at oracle dot com]

------- Comment #32 from paolo dot carlini at oracle dot com  2010-05-27 10:51 -------
You mean, in practice, we should only check that difference_type exists?


-- 


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[redi at gcc dot gnu dot org]

------- Comment #33 from redi at gcc dot gnu dot org  2010-05-27 11:54 -------
Alisdair checks for Iterator::iterator_category, which seems a very sensible
way of checking if a type wants to be recognised by iterator_traits

If iterator_category exists, then assume difference_type and the other nested
types do too.


-- 


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[paolo dot carlini at oracle dot com]

------- Comment #34 from paolo dot carlini at oracle dot com  2010-05-27 11:58 -------
Ok, let's do this, seems definitely an improvement, and since affects only
C++0x and enables more people to test it, I think should go in 4_5-branch too.
By the way, if I remember correctly, Howard used to do something very similar.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
                   |dot org                     |dot com
             Status|NEW                         |ASSIGNED


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[paolo dot carlini at oracle dot com]

------- Comment #35 from paolo dot carlini at oracle dot com  2010-05-27 16:25 -------
Note, plain pointers and pointers to const must be dealt with separately.


-- 


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[paolo at gcc dot gnu dot org]

------- Comment #36 from paolo at gcc dot gnu dot org  2010-05-27 17:37 -------
Subject: Bug 40497

Author: paolo
Date: Thu May 27 17:37:11 2010
New Revision: 159933

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159933
Log:
2010-05-27  Paolo Carlini  <paolo.carlini@oracle.com>

        PR libstdc++/40497
        * include/bits/cpp_type_traits.h (__is_iterator): Add.
        * include/bits/stl_iterator_base_funcs.h (next, prev): Use it.
        * testsuite/24_iterators/operations/40497.cc: New.

Added:
    trunk/libstdc++-v3/testsuite/24_iterators/operations/40497.cc
Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/bits/cpp_type_traits.h
    trunk/libstdc++-v3/include/bits/stl_iterator_base_funcs.h


-- 


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[paolo at gcc dot gnu dot org]

------- Comment #37 from paolo at gcc dot gnu dot org  2010-05-27 17:45 -------
Subject: Bug 40497

Author: paolo
Date: Thu May 27 17:44:59 2010
New Revision: 159934

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159934
Log:
2010-05-27  Paolo Carlini  <paolo.carlini@oracle.com>

        PR libstdc++/40497
        * include/bits/cpp_type_traits.h (__is_iterator): Add.
        * include/bits/stl_iterator_base_funcs.h (next, prev): Use it.
        * testsuite/24_iterators/operations/40497.cc: New.

Added:
   
branches/gcc-4_5-branch/libstdc++-v3/testsuite/24_iterators/operations/40497.cc
Modified:
    branches/gcc-4_5-branch/libstdc++-v3/ChangeLog
    branches/gcc-4_5-branch/libstdc++-v3/include/bits/cpp_type_traits.h
    branches/gcc-4_5-branch/libstdc++-v3/include/bits/stl_iterator_base_funcs.h


-- 


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

[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations

[paolo dot carlini at oracle dot com]

------- Comment #38 from paolo dot carlini at oracle dot com  2010-05-27 17:46 -------
Fixed for 4.5.1.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|4.4.5                       |4.5.1


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