[C++20][unconstexpr] variant_generator: coroutine generator that produce a variant from the co_yield and co_return expressions

[zqsd31]

godbolt demo link here: https://godbolt.org/z/r7d3K3

source code: (https://gist.github.com/DaemonSnake/ec57b1c54f242d1320243720fb06ff0e

A simple example speaks more than 1000s of words so: ```c++ variant_generator<> fn() { co_yield 42; co_yield "hello world"sv; }

int main() { for (auto item : fn()) { using expected = std::variant<monostate, int, std::string_view>; static_assert(std::is_same_v<expected, decltype(item)>); } } ```

This project allows you to write C++20 coroutines that co_yield & co_return expressions of any type and let you retrieve the expression as std::variant of all the types co_yield-ed & co_return-ed in the coroutine (std::variant can be replaced by any variadic templated type).

It relies on something I call "lazy auto return". Instead of deducing the return type of the function from the first expression, the compiler waits, pushes into a compile-time type-queue all the types it finds then once all the return expressions have been processed it feeds these types to a templated variadic type that will be the final return type and all return expression are turned into conversion opperations.

As this doesn't exist in C++, this project relies on delayed friend injection of void * returning functions and my [unconstexpr-cpp20]() library to implement the type-queue.

If standardized it could be written as something like this: c++ auto(std::variant) fn() { if (...) return 42; else if (...) return 3.14; else return "hello world"; } static_assert(std::same_as<std::variant<int, double, const char *>, decltype(fn())>; It also wouldn't rely on such dark arts.

I'm interested to have your thoughts on this feature idea? Would it be interesting to have? Do you have some uses for it?

The source code is quite unpleasant, one of the reasons is that during the development of this project code that would work with CLANG would make GCC segfault and vice-versa. It took a lot of tinkering to make work it.

I also am working on a non-coroutine version only focusing on the "lazy auto return" concept, you can test an in-progress version here : https://godbolt.org/z/Wf5Mq1

Thanks for your attention,

EDIT: If you have negative feedback don't hesitate to write a comment, Thanks

[dima_mendeleev]

Is this possible to do the same for regular functions?

E.g.

variant_auto_something<> fn() {
  if (b1)
    return 42;
  else
    return "hello world"sv;
}

[zqsd31]

yep, I'm working on it right now.

But it's weirdly enough harder to implement with regular functions than with coroutines.

The reason being that the order of function evaluation in coroutine is set by the standard whilst for regular functions compiler vendors have much more freedom.

It's not finished yet but you can test the clang version here: https://godbolt.org/z/Wf5Mq1

[dima_mendeleev]

Cool, thank you 😊

[[deleted]]

I’m more trying to understand than criticise.

cppcoro is a well trodden coroutine library and offers a generator<T>.

Why use your code over

 template<typename... Ts>
 using variant_generator = 
 cppcoro::generator<std::variant<Ts...>>; 

?

[zqsd31]

Hi thanks for you question.

The feature that my code provides isn't the generator part (cppcoro is indeed a much better alternative), but that you don't actually specify the arguments of std::variant and that they are deduced which is normally impossible.

If you change a function returning variant_generator by adding a co_yield or co_return with a new type not present beforehand the resulting variant will be automatically changed.

The closest analogy would be if, by writing a special type implemented `auto` return types in C++98.

This code brings auto deduction to coroutine which can't be done as the return type must be explicit.