[External] : Re: StructuredTaskScope and Futures

[Ron Pressler]

> On 4 Jan 2023, at 18:08, Florian Schmaus <flow at cs.fau.de> wrote:
> 
> If Future is replaced with Supplier, then you still have a get() method to call, right? So the temptation is still there (even if arguably in a weaker form). I am also not sure how one should map the 'throws' declarations of Future::get() to Supplier.
> 
> Which leads to me ponder if it wouldn't be better if StructuredTaskScope would orientate more on Cilk-ish semantic. That is, fork() would return a StructuredTaskResult with a get() method that will immediately return the result if invoked after a join(). And otherwise, if get() is invoked before a join point, get() would throw. So users that could not resist the temptation and misuse get() would get immediate feedback at run time. And I think this would make life easier for static code analysis tools to detect cases where get() is invoked before a join().
> 

That is exactly what Supplier.get() would do. It will not block, but throw an IllegalStateException if called before the scope is joined. There is no need for it to every throw any “logic” exception, because failures would be handled collectively by the policy immediately after joining. In the ShutdownOnFailure case, you would then call get once you know the forks have succeeded. In the ShutdownOnSuccess case, you won’t use the Supplier at all (just ShutdownOnSuccess.result()).

— Ron