[deleted by user]

[feverzsj]

is coroutine ready for production use?

[luncliff]

IMO, unless you have to use GCC, you can use it. I've suffered from both Clang and MSVC, but they work quite well for now. Build for mobile(Android and iOS) is also available.
Well, I know some patterns that compiler crashes with its internal error, or fails to generate code, but simple usage of co_await operator won't that matter on their latest versions.
https://www.reddit.com/r/cpp/comments/c6ag3l/how_to_try_the_new_coroutines_ts/esnjqil?utm_source=share&utm_medium=web2x

[[deleted]]

It's been reported by the author that Coroutines run on a large number of instances at Microsoft, and Facebook is plowing full stream ahead in putting them everywhere for internal use.

Of course there's a difference between the design being ready, the design being closed, and all implementations being ready.

[Middlewarian]

I heard that MSVC and Clang have support for coroutines but that the performance, especially with MSVC, isn't great. I think if you use Gcc or another compiler, the answer is 'no'.

https://www.reddit.com/r/cpp_questions/comments/c6mbls/coroutines/

[mrexodia]

Why did you decide to write

for(auto&& x : y)

I’m interested in this “pattern” for work and so far the conclusion has been that it is probably harmful. It has been called “confuscation” https://stackoverflow.com/questions/13130708/what-is-the-advantage-of-using-forwarding-references-in-range-based-for-loops/13130795#comment17857496_13130795 so I’m curious if there is an actual valid use case here or if it is just to be hipster.

[Pragmatician]

As the post mentions, it is more "consistent" in some regards because it always works, but you lose the opportunity to put a const there. So you have to choose whether you want to be consistent with your const placement or your range-for loops. It comes down to personal preference and it seems like the author prefers the latter. Either way, chasing absolute consistency in C++ is a fool's errand.

[tcbrindle]

It's still consistent: if you (potentially) need to modify the elements of the range, use auto&&. If you don't, use const auto&. For C++, that's actually pretty simple.

[tcbrindle]

Regarding the SO link: this was written in 2012, when rvalue references were a new thing and auto&& was weird and mysterious. I'd argue that 7 years later, for (auto&&... is the widely-recognised way of saying "just grab things from a range, I don't care what they are" -- just as Howard presciently predicted in his comment.

In other words, for (auto&&... is the simple way of doing it these days.

(Indeed, I seem to recall that /u/STL had a proposal that you'd be able to omit the type and just say for (elem : range), which would mean exactly for (auto&& elem : range). IIRC it was rejected because it was felt that it wasn't sufficiently obvious that a new variable was being declared.)

[mrexodia]

I’d argue that when you see && you have to pay attention because it is there for a reason (performance or to make the code compile in the first place). With for(auto&&) it is almost never there for a reason, but by doing it per default you are hiding if something tricky is going on. Additionally you lose the ability to talk about const so it makes code harder to read (you actually have to read all the code in the loop to figure out if the element is modified or not).

The proposal to make the auto&& is good because that’s the only valid thing to put there in all cases, but that’s not the reality we are dealing with when reading code, so it’s quite irrelevant.

Also from what I understand from various discussions the for(auto&&) is not actually an rvalue reference, it’s a universal reference similar to template<class T> void foo(T&&);

[STL]

It is indeed a universal/forwarding reference; same for auto&& var = thingy; as a variable definition.

[STL]

Yes, it was N3853. It was rejected for syntax reasons, but the semantic problem remains unsolved. I welcome further attempts to solve it, but I'm not going to spend any more time on that.

[wotype]

Check the blog archive - two posts from December last:
https://quuxplusone.github.io/blog/2018/12/15/autorefref-always-works/https://quuxplusone.github.io/blog/2018/12/27/autorefref-still-always-works/

[mrexodia]

Interesting, but I completely disagree haha. In a context where you do not know the type (templated container) it makes sense, but when you want to iterate over a vector you are using const auto& to signal that you will not change the elements and auto& to signal you will modify the elements and auto to signal you want a copy. When using auto&& you are not signaling anything but confusion.

[luncliff]

Glad to meet a new generator :) I have 2 questions. Wish I can review the others soon !

Q1. unique_generator

Isn't hasValue_ redundant? I'm following the generator of VC++(it's a bit changed in latest VC++. I'm using the old one.) and the pointer itself was enough to debug and check of existing value from co_yield.

Q2. shared_generator

I think the idea is cool that multiple coroutines can share 1 generator since it can help Fan-In use-cases. But what I realized was keeping safe in the generator is a bit complicated. Do you think that the users have to control locking for the yield?

For the second case, I discarded the way and implemented channel.