[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52114 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #14 from Jonathan Wakely --- Indeed, this was fixed for 5.1 (and now gives 200+ lines of diagnostic output instead of 9 - yay!)
[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52114 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #13 from Ville Voutilainen --- This bug has been fixed, we do nowadays SFINAE in these return types.
[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages
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((ot), 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
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.
[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages
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
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
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
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
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
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
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
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((ot), std::ostream) would solve that.
[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages
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
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 ;)
