What would you do...

[Timon Gehr]

On 12/09/2011 12:21 AM, Manu wrote:
>         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.

That could be useful in many different contexts, some more clean than 
this one.

> 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. :/
>

Well, it cannot be taken. And how it works exactly is an implementation 
detail of std.concurrency. The bug you are talking about does not exist. 
So I don't quite follow. I agree that maybe using an explicit boolean 
template parameter to distinguish the two cases would be cleaner, and 
that is how I usually handle that kind of code reuse.


>         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 >_<

It certainly is, but 'is' expressions still need some fixing. The code 
currently tests whether or nor t1 is a function type or a delegate type. 
However, it looks like it should test for function pointer or delegate. 
I'd like that fixed, but it is a breaking language change...

> 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++ ;)

Note that since the language is simpler, the bar of what you can 
actually reasonably well do with it is higher. Equivalent C++ code would 
likely be harder to follow.