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.
