What would you do...

Manu turkeyman at gmail.com
Thu Dec 8 15:21:42 PST 2011


>
> 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.
>>
>
> Sure, receive cannot be called with duration. You pass callbacks to it,
> not Durations. Callbacks are never implicitly convertible to Durations, so
> that is fine.


Ah crap, I DID miss the magic detail in checkops() you mentioned below.
That clears it up.
However I still feel this construct is quite dangerous. I'm looking at it
from a programming 'pattern' point of view rather than the details of this
case specifically. I don't know if I've illustrated my concern clearly
though...


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

I don't see a 'pattern'.

I refer to the concept ('pattern' if you will) of receiving a tuple of
args, and then comparing the first as a specific type instead of using a
function overload.
ie. in this example with the optional first Duration parameter, but with
the assumption that the following parameters may be of any type. This
'pattern' may lead to a bug where if the first Duration parameter were not
desired, but the second parameter happened to be any type that implicitly
converted to a Duration, then the wrong code path could be taken without
the programmers knowledge... I hope that makes sense. :/


>  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?
>>
>
> Have a look at the checkops template. It catches your case.
> I just saw it contains another bug though:
>
> static assert( is( t1 == function ) || is( t1 == delegate ) );
>
> Obviously, the writer meant to check for function pointers and delegates.
> This is not what it does. Borken. I think the language should be fixed here.
>

I can't see the problem >_<
I must confess, I'm finding some D code I look at REALLY hard to follow...
like this code for instance (mbox.get()). Granted, I'm not yet very good at
reading D code, which often appears nothing at all like C/C++, but I'm
hoping the language is overall a *simplification* over C/C++ ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111209/85b42c21/attachment-0001.html>


More information about the Digitalmars-d mailing list