[cpp-threads] Asynchronous Function Proposal

[Peter Dimov]

Boehm, Hans:
...

> I'm still unsure what the programming rules for thread_locals should be. 
> And without that, it seems to be hard to answer these questions.
>
> I think most people are arguing for an approach in which client code has 
> to be very careful about storing unknown data D with nontrivial 
> destructors into thread_locals, so that we can be sure that D is destroyed 
> while it is still safe to do so, just as you would with static duration 
> variables.  In that case, we might be able to allow running on another 
> thread.
>
> My only problem with this is that it makes it very hard to use 
> thread_locals in generic library code, e.g. to cache the last value I 
> looked up in a map.

I'll try to use an analogy to show why I have a severe problem with this 
reasoning. It took me a while to distill it, and it's not perfect. Still.

I see you as saying the equivalent of:

- I can easily write a type X such that std::set<X> crashes and burns.
- I can think of no way to write std::set so that it doesn't crash and burn 
when fed X.
- Therefore, std::set is very hard to use in generic code, because someone 
may feed X to it.
- Therefore, std::set must be removed from the standard.

The hundreds of thousands of C++ programmers that use std::set every day 
somehow don't enter the equation, and neither does their pragmatic solution 
to the problem - use it when it works, do not use it when it doesn't.