I don't get the point of ready() in n3634. In the example the code creates an async operation and gets a future (f1) then checks whether it is ready. If it is ready then it processes its result and if it is not ready then it attaches a new future (f2) that will process the result later. In my opinion it would be better to hide this check from the user. The user should simply give a piece of code that will be executed when the value is ready. The user should not have to care when the result is available.

I can't come up with a real life example where you really need to do the check using ready() and code executed after ready() is not identical to the code executed in the second continuation. If they are identical then the only advantage of using ready() is better efficiency (which is mentioned in 3634 and also by cparen) but in that case this piece of code with ready() could be in a library and the programmers won't have to rewrite this if again and again. That's my opinion.

I agree that checking whether the value is ready is more efficient and I did not try to argue that the check should not be done. I just said that it should not be done by the programmer. I don't know if it can be done by a sufficiently smart library code or it really requires a new keyword or compiler support. Either way, this looks like something that could be automated. I'll take a look at n3772, thanks.