I have some code (a simulation style solution to the Sleeping Barber problem). It uses spawned processes to represent the actors of the system. The code compiles and executes as expected using GDC as currently on Debian Unstable, which I believe is effectively D 2.057. Using DMD 2.058 I get the error message:


/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/concurrency.d(529): Error: cannot have parameter of type void
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/concurrency.d(529): Error: cannot have parameter of type void
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/concurrency.d(529): Error: variable std.concurrency.receive!(void delegate(Customer customer) @system,void,void).receive._param_1 voids have no value
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/concurrency.d(529): Error: variable std.concurrency.receive!(void delegate(Customer customer) @system,void,void).receive._param_2 voids have no value
Failed: 'dmd' '-v' '-o-' 'singleBarber_d2_spawn.d' '-I.'


Using  DMD 2.059 I get the error message:

singleBarber_d2_spawn.d(35): Error: template std.concurrency.receive does not match any function template declaration
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/concurrency.d(530): Error: template std.concurrency.receive(T...) cannot deduce template function from argument types !()(void delegate(Customer customer) @system,void,void)
singleBarber_d2_spawn.d(59): Error: template std.concurrency.receive does not match any function template declaration
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/concurrency.d(530): Error: template std.concurrency.receive(T...) cannot deduce template function from argument types !()(void delegate(Customer customer) @system,void delegate(SuccessfulCustomer successfulCustomer) @system,void delegate(ShopClosing message) @system,void delegate(ClockedOut message) @system,void)
singleBarber_d2_spawn.d(99): Error: template std.concurrency.receive does not match any function template declaration
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/concurrency.d(530): Error: template std.concurrency.receive(T...) cannot deduce template function from argument types !()(void delegate(Tid t) nothrow @safe,void delegate(Customer customer) @system,void delegate(SuccessfulCustomer successfulCustomer) @system,void,void)
Failed: 'dmd' '-v' '-o-' 'singleBarber_d2_spawn.d' '-I.'

the "offending" bit of code is:

   receive (
             ( Customer customer ) {
               writeln ( "Barber : Starting Customer " , customer.id ) ;
               Thread.sleep ( hairTrimTime ( ) ) ;
               writeln ( "Barber : Finished Customer " , customer.id ) ;
               ++customersTrimmed ;
               shop.send ( SuccessfulCustomer ( customer ) ) ;
             } ,
             ( ShopClosing ) {
               writeln ( "Barber : Work over for the day, trimmed " , customersTrimmed , "." ) ;
               shop.send ( ClockedOut ( ) ) ;
               running = false ;
             } ,
             ( OwnerTerminated ) { }
             ) ;

Where Customer and SuccessfulCustomer are structs as the case types -- so that the shop can distinguish new arrivals from trimmed customers.

So somewhere between 2.057 and 2.058 it seems that something about receive changed, as far as I am concerned from correct to fail -- however I may have missed a memo...

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 04/18/2012 11:18 AM, Russel Winder wrote:

> Using  DMD 2.059 I get the error message:
>
> singleBarber_d2_spawn.d(35): Error: template std.concurrency.receive does not match any function template declaration
> /home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/concurrency.d(530): Error: template std.concurrency.receive(T...) cannot deduce template function from argument types !()(void delegate(Customer customer) @system,void,void)

I have hit this problem earlier. Here is a reduced code:

import std.concurrency;

struct S
{}

void main()
{
    receive((S) {});  // <-- compilation error with 2.059
}

The workaround is to name the parameter:

    receive((S s) {});

Ali

On Wed, 2012-04-18 at 15:04 -0700, Ali Çehreli wrote: [...]
> The workaround is to name the parameter:
> 
>      receive((S s) {});

OK, this works for me as well, which is great. The question now is whether this is a feature or a bug?  In terms of the parameter list of a function literal, the names should be there so requiring the name is fixing a bug that was there. In terms of usability in context, if the programmer doesn't use the variable just the fact that an instance of the type was received, then having to give the variable a name is total noise. In this case the old behaviour was right and the change created a new bug.

I guess this is a situation where "Walter Decides" ?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 04/19/2012 10:09 AM, Russel Winder wrote:
> On Wed, 2012-04-18 at 15:04 -0700, Ali Çehreli wrote:
> [...]
>> The workaround is to name the parameter:
>>
>>       receive((S s) {});
>
> OK, this works for me as well, which is great. The question now is
> whether this is a feature or a bug?  In terms of the parameter list of a
> function literal, the names should be there so requiring the name is
> fixing a bug that was there. In terms of usability in context, if the
> programmer doesn't use the variable just the fact that an instance of
> the type was received, then having to give the variable a name is total
> noise. In this case the old behaviour was right and the change created a
> new bug.
>
> I guess this is a situation where "Walter Decides" ?
>

The issue is that the meaning of (S) {} in non-template delegate signatures has changed: Previously it was a delegate with an unnamed parameter of type 'S', now it is a delegate with a parameter named 'S' of a deduced type. I think that the second meaning is more useful and more consistent, but YMMV. (You can name the parameter '_' or something along those lines to express that it is not used.)

On Thu, 2012-04-19 at 18:06 +0200, Timon Gehr wrote:
[...]
> The issue is that the meaning of (S) {} in non-template delegate signatures has changed: Previously it was a delegate with an unnamed parameter of type 'S', now it is a delegate with a parameter named 'S' of a deduced type. I think that the second meaning is more useful and more consistent, but YMMV. (You can name the parameter '_' or something along those lines to express that it is not used.)

OK, so I missed the memo, my fault.

Is _ just a valid name that can be used in a conventional way, or is it an unallocated variable?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 04/19/2012 06:23 PM, Russel Winder wrote:
> On Thu, 2012-04-19 at 18:06 +0200, Timon Gehr wrote:
> [...]
>> The issue is that the meaning of (S) {} in non-template delegate
>> signatures has changed: Previously it was a delegate with an unnamed
>> parameter of type 'S', now it is a delegate with a parameter named 'S'
>> of a deduced type. I think that the second meaning is more useful and
>> more consistent, but YMMV. (You can name the parameter '_' or something
>> along those lines to express that it is not used.)
>
> OK, so I missed the memo, my fault.
>
> Is _ just a valid name that can be used in a conventional way, or is it
> an unallocated variable?
>

It is a valid identifier.