What would you do...

[Sean Kelly]

On Dec 8, 2011, at 8:23 AM, Manu wrote:
> 
> Just digging through concurrence.d since the docs are pretty bare, and I've come across this pattern, which raises a pretty worrying alarm to me. I wonder if this is common in D libraries...
> 
> ...
> 
> No overload, receives a tuple, and assumes that static-if the first tuple item is IMPLICITLY CONVERTIBLE to a Duration, I must be calling the 'overload'...
> 
> I guess this means I can never pass a Duration in a message to the non-timeout receive()... or anything that is implicitly convertible to a Duration.

Right.  The only thing you can pass to receive() are functions taking one or more parameters.  mbox.get() itself is actually pretty lax in enforcing this because it relies on the caller to do most of the filtering (via checkops).  This should be safe since the mbox itself is private.  I suppose I could have done this a different way, but overloading when one function has (T…) args is a bit weird.


> This would seem to be a very obscure hidden bug to me. Is this a common pattern in D?

It's probably the only case.


> I certainly wouldn't want to be tracking down this bug on build night... Is there something I've missed here? Some sort of safeguard I've overlooked?

See above.  MessageBox is private and receive() does the parameter checking.