On Mon, Sep 14, 2020 at 3:50 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Mon, Sep 14, 2020 at 3:05 PM Barry Revzin via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>
> > As I said in https://lists.isocpp.org/std-proposals/2020/09/1811.php,
> this already exists in C++20 in the form of coroutines...
>
> We *really* don't want to abuse coroutines for that.


I don't know who "we" is, but this certainly isn't "abuse" - this is a
perfectly reasonable use of coroutine.


> Making a function
> a coroutine causes fundamental changes that alter how that function
> gets to interact with the rest of the world. For example, coroutines
> can't participate in guaranteed elision (or even non-guaranteed
> elision). Also, it forces you to use `co_return` to return, just
> because you wanted to exit elsewhere.
>
> And adding coroutine machinery to a type requires expert-level
> understanding, far beyond the needs of just writing an `optional`-like
> type. That shouldn't be required for doing something like this.
>

Only one person needs to do this for optional one time, it's not something
that everybody needs to do for every function. And there are already sample
implementations of adding coroutine support to types like optional.


>
> Now, that being said, I think the idea is not a good one. If we had
> light-weight exceptions, we wouldn't need to use `optional` for cases
> like this or ValueOrError types like these at all. We could just write
> reasonable code and let a catch block handle the rest.
>

I don't know what this has to do with exceptions. Exceptions don't obviate
the need for an optional type... using optional isn't strongly tied to
error handling at all.

Barry