Asynchronous concurrency with reference types

[spir]

On 02/05/2011 06:42 PM, Peter Alexander wrote:
> On 5/02/11 12:11 AM, Sean Kelly wrote:
>> Peter Alexander Wrote:
>>>
>>> Things might be easier if the error messages associated with D's
>>> concurrent features weren't especially unhelpful (for example, trying to
>>> spawn a thread with reference type parameters just gives you a 'no match
>>> for spawn template' error). It's nice that it stops you from doing such
>>> things, but it would be nice if it told me why it's not going to let me
>>> do them.
>>
>> Could you provide an example? When passing reference data, the error you
>> should see is: "Aliases to mutable thread-local data not allowed." It's a
>> static assert inside send().
>
> Now that I've investigated a bit more, it appears to be unrelated to reference
> types, and instead was an error about using a nested function:
>
> import std.concurrency;
> void main()
> {
> void foo() {}
> spawn(&foo);
> }
>
> ---
> test.d(5): Error: template std.concurrency.spawn(T...) does not match any
> function template declaration
> test.d(5): Error: template std.concurrency.spawn(T...) cannot deduce template
> function from argument types !()(void delegate())
> ---
>
> Why does it think that the function is a delegate?

In complement to what Denis Koroskin answered: when a func is defined inside 
another one, taking what looks like a func pointer to it automatically turns 
the result into a delegate.
I also find this annoying, even more because there is no automagic func* <--> 
delegate cast.

What I would like id:
* No func* / delegate distinction on the user side (can be impl optimisation if 
significant).
* Function auto-de/referencing: meaning in your code: spawn(foo).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com