On 06/20/2014 03:11 PM, Jason Merrill wrote:
On 06/19/2014 01:29 PM, Marc Glisse wrote:
That looks weird to me. The const&& version is a better match than the
const&, so we should pick that one in overload resolution, but if we
remove the const&& version, the other one seems valid to me
Hmm, y
On 06/19/2014 01:29 PM, Marc Glisse wrote:
That looks weird to me. The const&& version is a better match than the
const&, so we should pick that one in overload resolution, but if we
remove the const&& version, the other one seems valid to me
Hmm, you're right, I was confused.
Jason
On Thu, 19 Jun 2014, Jason Merrill wrote:
We were treating a const & member function like a normal const reference, and
binding an rvalue object argument to it. But it doesn't work that way.
That looks weird to me. The const&& version is a better match than the
const&, so we should pick that
On 06/19/2014 12:12 AM, Jason Merrill wrote:
We were treating a const & member function like a normal const
reference, and binding an rvalue object argument to it. But it doesn't
work that way.
In 4.9 we also need to set LOOKUP_NO_TEMP_BIND.
commit 48ca9803695872d984b0f4efa56f7f58987d0928
A
