explicit castable to bool for predicate restraints?

[Jonathan M Davis]

On Tuesday, December 18, 2012 01:45:14 Jonathan M Davis wrote:
> On Tuesday, December 18, 2012 10:23:18 monarch_dodra wrote:
> > On Monday, 17 December 2012 at 23:40:19 UTC, Jonathan M Davis
> > 
> > wrote:
> > > On Monday, December 17, 2012 10:23:45 monarch_dodra wrote:
> > >> Opinions? Just want to know how which direction to take my
> > >> future
> > >> developments.
> > > 
> > > How about we just require that they all return bool? I see no
> > > reason to
> > > support anything else.
> > > 
> > > - Jonathan M Davis
> > 
> > That seems excessive to me. I think a lot of predicates,
> > especially if they have C linkage, will return a (u)int whose
> > values are just 0 or 1. I see no reason to not support this.
> 
> Then wrap them in a lambda. int is not a boolean value in D, and I really
> don't think that we should be treating it as such. No D functions should be
> returning int for a boolean value, and I would expect using C functions with
> std.algorithm to be quite rare.

We're probably stuck with std.algorithm allowing implict conversions to bool 
due to the fact that a fair bit of it has accepted that for a while, but 
accepting anything which explictly casts to bool would be tantamount to 
turning explicit casts into implicit casts and would be very dangerous. The 
language is _very_ restrictive about where it does that precisely because of 
all the problems caused by implicit conversions in C++. Conditions inside of 
if statements and loops are the only place in the language where an explicit 
cast is implicitly done. And it's somewhat surprising that it does even that 
given how restrictive it is about implicit conversions in general. Everywhere 
else, an explicit cast is required to get an explicit cast. It's trivial to 
create a lambda to wrap functions which require explicit casts.

- Jonathan M Davis