[Bug libstdc++/52114] New: SFINAE out the rvalue iostream operators to give better error messages

[Bug libstdc++/52114] New: SFINAE out the rvalue iostream operators to give better error messages

[b.r.longbons at gmail dot com]

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

             Bug #: 52114
           Summary: SFINAE out the rvalue iostream operators to give
                    better error messages
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: b.r.longbons@gmail.com


Created attachment 26566
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26566
Use SFINAE in delayed return type to make sure there's an lvalue version

Currently, if there is no stream insertion/extraction operator defined for a
class, it tries to use the template that takes an rvalue istream or ostream and
anything on the right.

Actual Result:
error: cannot bind ‘std::ostream {aka std::basic_ostream<char>}’ lvalue to
‘std::basic_ostream<char>&&’
/usr/include/c++/4.6/ostream:581:5: error:   initializing argument 1 of
‘std::basic_ostream<_CharT, _Traits>&
std::operator<<(std::basic_ostream<_CharT, _Traits>&&, const _Tp&) [with _CharT
= char, _Traits = std::char_traits<char>, _Tp = Foo]’

Expected Result:
error: no match for ‘operator<<’ in ‘std::cout << Foo()’
note: candidates are:

Note that this patch is not safe to apply to 4.6 because of bug 51878

[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-02-04
     Ever Confirmed|0                           |1
           Severity|normal                      |enhancement

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-04 19:01:47 UTC ---
seems like a good idea

[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler at
                   |                            |googlemail dot com

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-02-04 20:32:31 UTC ---
Indeed and easy to do.

Yesterday I was wondering: is there something in C++11 saying explicitly that
these tricks are allowed, or some sort of blanket statement explaining how the 
return type specifications are meant to be read? Adding Daniel in CC.

[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-02-04 20:39:58 UTC ---
(PS: Daniel tweaked tuple_cat the same way)

[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages

[daniel.kruegler at googlemail dot com]

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

--- Comment #4 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2012-02-04 21:44:24 UTC ---
(In reply to comment #3)
> (PS: Daniel tweaked tuple_cat the same way)

There is a difference here: For tuple_cat we have a user constraint that says
that the template argument shall be a tuple_cat, but encourage the library to
support other types satisfying the tuple-like protocol. Further, tuple_cat is a
named function and hard to reach unintentionally. I tend to say that the
approach here is what a good library should do. But it might be a good idea to
open a library issue to require a reduced set of overload resolution
participation for any conforming implementation for the new two generic
inserter and extractor.

[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages

[b.r.longbons at gmail dot com]

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

--- Comment #5 from Ben Longbons <b.r.longbons at gmail dot com> 2012-02-04 22:36:54 UTC ---
(In reply to comment #2)
> Yesterday I was wondering: is there something in C++11 saying explicitly that
> these tricks are allowed,
In N3242, 14.8.2/{7,8}

[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-02-04 22:49:17 UTC ---
Thanks Daniel.

Ben, I know SFINAE ;) what I was looking for is something *in the library*
chapters saying somehow explicitly that for overload resolution purposes or
other QoI purposes late return types are fine (vs the letter of the specs in
terms of return types)

[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-04 22:53:11 UTC ---
(In reply to comment #5)
> (In reply to comment #2)
> > Yesterday I was wondering: is there something in C++11 saying explicitly that
> > these tricks are allowed,
> In N3242, 14.8.2/{7,8}

The question is not about the language rules, we know it works. The question is
whether modifying the signature of the function is allowed. It would change the
return type if called for a type that overloads operator<< with a return type
that is not ostream&

[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-04 22:54:51 UTC ---
But using decltype((o<<t), std::ostream&) would solve that.

[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-02-04 22:58:06 UTC ---
Jon, interesting

[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

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

--- Comment #10 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-02-04 22:59:54 UTC ---
I mean, your idea seems a nice operative answer to my vague nervousness ;)

[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages

[daniel.kruegler at googlemail dot com]

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

--- Comment #11 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2012-02-05 11:00:00 UTC ---
(In reply to comment #8)
> But using decltype((o<<t), std::ostream&) would solve that.

I agree that this would be much better but I suggest to cast the first
expression to void to prevent overloaded operator, to be in effect here. I
still think that a library issue should be opened for this.

[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages

[paolo.carlini at oracle dot com]

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

--- Comment #12 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-02-05 11:11:34 UTC ---
I agree it should, thanks Daniel. In fact, I see that implementing the trick in
a fully correct way is less than trivial and, AFAIK, there is no hint at all in
the Standard that something similar is in order.