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

Subject: Re: [boost] [operators] The future of Boost.Operators
From: Daniel Frey (d.frey_at_[hidden])
Date: 2013-04-22 16:42:22

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.

Or are there any other issues that I fail to see?

Regards, Daniel