On Friday, 24 January 2014 at 11:00:42 UTC, Dicebot wrote:

> D type system is supposed to guarantee that you never ever can get pointer/reference to data that is not stored in your own TLS (including stack) unless it is marked as shared (immutable / __gshared are in shared category).

Agreed.

> By allowing to spawn thread with a delegate which has context pointer not qualified as shared you break that type system sanity rule.

Agreed again. AFAIK, that was the exact reasoning behind restricting std.concurrency to not allow delegates as thread functions or message types.

> Multithreading / concurrency in D is quite different from C++.

With this I cannot completely agree. Granted, we have "shared" qualifier and by-default-TLS static data. Oh, and built-in monitors + synchronized methods (which are of dubious value at best). In that, D differs. But the bare bones of concurrency still are the same. Access to shared data still has to be manually synchronized somehow (locks, atomics, cas, you name it). Threads still have to be spawned and joined as necessary.

Ok, we have some of the boilerplate removed thanks to std.concurrency and std.parallelism, but that's just library solutions, not unlike those that exist for C++. I.e. there's nothing in the language that says "use that!".

And sadly, when threading is concerned, purity doesn't help much because of the "weak purity" concept.

> Delegates unique in a sense that they often erase type qualifiers for the context because of rather hacky current implementation. All such cases are bugs that contradict language spec, there is nothing intentional about it.
>
> There are no legal exceptions to the rule "all shared data must be shared".

Agreed.

Oh, speaking of holes in the type system. Synchronization primitives like Mutex, Condition, etc. (which should be de-facto shared) aren't qualified as shared. Do you know if it's intentional or?..