std::variant doesn't support references either (that was a late decision, IIRC) I'm not sure it or optional ever will. Although maybe expected use cases could lead the way. Some committee members want references to work one way, some want it to work another, some think it is dumb to put non-Regular types into optional, so we should *never* support references. Tony On Thu, May 25, 2017 at 4:33 PM, Vicente J. Botet Escriba via Boost wrote:

Le 25/05/2017 à 19:33, Andrzej Krzemienski via Boost a écrit :

...

Niall, Are Boost.Outcome monads intended to work with references (at least lvalue references)?

<snip>

If I try it with `outcome::expected` I also get these messages, but I also get a static assert saying that as per LWG decision T must be default constructible.

Vicente, does this mean you cannot use `std::expected` to return references?

The proposal doesn't includes it. I have a open point to know if the committee is interested in. As we don't have yet optional I believed that it could be done later on. However variant supports references, isn't it?

Vicente

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2017-05-26 0:01 GMT+02:00 Peter Dimov via Boost :

Gottlob Frege wrote:

Some committee members want references to work one way, some want it to

...

work another, ...

More specifically, some want in

T t1, t2; expected e1( t1 ), e2( t2 );

e1 = e2;

t1 to be assigned t2, whereas others want e1 to start pointing to t2. Similarly for e1 = t2.

From what I remember the biggest controversy in boost::optional was about the assignment from T:

``` T v1, v2; optional ot (v1); ot = v2; ``` You do not have to solve this prolem in `expected<>`. Also, the Standard has a precedent for this: std:reference_wrapper: it rebinds on assignment.

so we should *never* support references.

...

Sounds like a good plan to me.

Then you will have to work aroun with `expected`. Regards, &rzej;

2017-05-26 0:29 GMT+02:00 Niall Douglas via Boost :

On 25/05/2017 18:33, Andrzej Krzemienski via Boost wrote:

...

Niall, Are Boost.Outcome monads intended to work with references (at least lvalue references)?

The current code no. And I deliberately left out a static assert until feedback came from here.

...

I get lots of compiler errors. But the messages ("constructor cannot be overloaded") indicate that it was just an omission and not a design decision.

I did leave my options open just in case. But more support code would be needed.

...

If I try it with `outcome::expected` I also get these messages, but I also get a static assert saying that as per LWG decision T must be default constructible.

Vicente, does this mean you cannot use `std::expected` to return references?

Neither std::variant nor std::optional support references, and neither does std::expected in its current proposal.

Unless reviewers here are super keen on supporting outcome, I'll be adding a static assert forever preventing them soon.

But not providing them means that if I have function that returns a reference and signals failures by, say output function parameter: ``` T& find_smallest(std::array & array, std::error_code & err); ``` I will never be able to "modernize" it to use `outcome` or `expected`. Regards, &rzej;

...

Unless reviewers here are super keen on supporting outcome, I'll be adding a static assert forever preventing them soon.

But not providing them means that if I have function that returns a reference and signals failures by, say output function parameter:

``` T& find_smallest(std::array & array, std::error_code & err); ```

I will never be able to "modernize" it to use `outcome` or `expected`.

I know you won't like this answer, but I'd just return a T* and dereference it :) But to be more serious, the way I've solved that exact problem in my own code is: ``` expected find_smallest(std::array & array); ``` span's be amazing, they are effectively Rust's borrowed references. I use them a lot. I appreciate that is a workaround rather than a solution. But once you start using spans a lot, you **never again** return references from a function. References become only ever used for inputs, never outputs. Which is a very, very good thing and your code will be much better for it. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/