id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
10664,Missing support with respect to moves,anonymous,olli,"Some parts of the documentation suggests that coroutines can be used with move-only types (e.g. boost::coroutines::asymmetric_coroutine<std::unique_ptr<int>>):

> If R is a move-only type, you may only call get() once before the next asymmetric_coroutine<>::pull_type::operator() call.

> However, if the template parameter is a move-only type, symmetric_coroutine<>::yield_type::get() may only be called once before the next symmetric_coroutine<>::yield_type::operator() call.

However those get members are implemented as some form of return * result_;, where the result type is that move-only type. This rightfully won't work.

Note that using the input iterator (in the asymmetric case) works, because its operator* uses the get_pointer() member (of the non-public implementation) rather than get().

My first thought on how to solve this is to elaborate the public interface, as I believe only one get() member won't cut it. Even if e.g. get() performs some equivalent of return move(*result_); for move-only types, there is a missed opportunity for copyable types that have an optimized move. Consider a coroutine of std::vector<int>, for which we only call get() at most once per value yielded: we would like each value to be passed around with moves, to avoid unnecessary allocations.

IOW, there is a clear separation of concerns between a getter that can be called at most once, for which returning by value is a natural fit; and a getter that can be called any number of times, for which returning by value is not unheard of, but in which case it shouldn't compile for move-only types--although the presence and uses of get_pointer() suggests a need for returning by reference. This makes it possible at all to write correct generic code, too:

{{{
auto f(Functor functor, Coro& coro)
{
    // for a double-duty get(), we can't tell if
    // we're performing two moves (which is bad)
    // or two copies (which could be inefficient)
    return functor(coro.get(), coro.get());

    // okay: this won't compile for move-only types, and
    // this performs the required work when we really need
    // additional copies
    return functor(coro.get_copy(), coro.get_copy());
    // a savvy programmer that wants as few copies as possible,
    // when moves are assumed to be acceptable, has the tools
    // to achieve that goal:
    auto copy = coro.get_copy();
    return functor(move(copy), move(coro.get_reference()));
    // minimal work: one copy, one move
    // possible thanks to the sequencing guarantees of { }
    return Foo { coro.get_copy(), move(coro.get_reference) };

    // okay, doesn't even require moveability
    return functor(coro.get_reference(), coro_get_reference());

    // not okay, can't be caught by the compiler but hopefully
    // obvious to the programmer
    return functor(coro.get_move(), coro.get_move());
}
}}}

(The names are painfully spelled out for the purpose of illustration and not a serious suggestion.)",Bugs,closed,To Be Determined,coroutine,Boost 1.56.0,Problem,wontfix,,