Re: [boost] [operators] The future of Boost.Operators

Subject: Re: [boost] [operators] The future of Boost.Operators
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-04-24 02:52:40

On Tue, Apr 23, 2013 at 12:42 AM, Daniel Frey <d.frey_at_[hidden]> wrote:

> On 22.04.2013, at 22:10, Marc Glisse <marc.glisse_at_[hidden]> wrote:
>
> > On Mon, 22 Apr 2013, Daniel Frey wrote:
> >
> >> I would like to discuss the future of Boost.Operators, as several
> issues and options have piled up in the past. Here are some points to take
> into account:
> >>
> >> 1) Support for rvalue references to generate fewer temporaries. (where
> available)
> >
> > I notice that some of your operators return rvalue references. It seems
> that everybody tries that, and eventually goes back to returning plain
> rvalues (see the discussion about boost.multiprecision for instance).
>
> The only "issue" that I am aware of is that you can no longer extend the
> returned temporary's lifetime by binding it to an lvalue reference. My
> problem with this argument is that I don't buy it. If someone writes:
>
> const A& r = a + b + c; // (1)
>
> instead of
>
> const A r = a + b + c; // (2)
>
> then I would really say it's the user's fault. Why? Because you always
> need to check if operator+ returns a value and not a reference. Simply
> assuming it does without checking the documentation (not the
> implementation!) is a bug. If a library/class/... does not guarantee that a
> function (or operator) returns a value, one should not rely on being able
> to use (1) and always use (2) instead.
>

I disagree. I mean, what is the C++03 case that would make (1) invalid
before? The operator returns either rvalue or a reference (which is assumed
to be bound to some stable value), and both cases work well with (1). And
if (1) is valid in C++03 then why should it become invalid in C++11?