Actually I think this might be a DMD bug.

!match() compiles too.

This is the same for basic types.

bool foo(){return 2;}  // error
bool bar(){return !2;} // fine

I don't think we are looking at a bug here.

(In reply to comment #2)
> This is the same for basic types.
> 
> bool foo(){return 2;}  // error
> bool bar(){return !2;} // fine
> 
> I don't think we are looking at a bug here.

Are you saying that type conversion isn't supposed to happen when a value is returned?

http://www.d-programming-language.org/statement.html#ReturnStatement says:

"The Ex­pres­sion is im­plic­itly con­verted to the func­tion re­turn type."

Neither int (outside the range [0,1]) nor RegexMatch implicitly convert to bool. Negating counts as an explicit cast to bool.

(In reply to comment #4)
> Neither int (outside the range [0,1]) nor RegexMatch implicitly convert to
> bool. Negating counts as an explicit cast to bool.

As far as I can tell, RegexMatch does implicitly cast to bool.

struct RegexMatch {
  T opCast(T : bool);
}

I could be missing something, but this effectively declares an opCast!bool operator.

http://www.d-programming-language.org/operatoroverloading.html#Cast claims that both ! and bare references will get rewritten to opCast!bool:

  if (e)   =>  if (e.opCast!(bool))
  if (!e)  =>  if (!e.opCast!(bool))

That should take care of the return, no?

Note that the same compile failure happens if I write:

  auto re = regex("test");
  if (match("test", re)) { ... }


It strikes me that the language docs are rather sparse on defining what can and cannot be implicitly converted.

(In reply to comment #5)
> (In reply to comment #4)
> > Neither int (outside the range [0,1]) nor RegexMatch implicitly convert to
> > bool. Negating counts as an explicit cast to bool.
> 
> As far as I can tell, RegexMatch does implicitly cast to bool.
> 
> struct RegexMatch {
>   T opCast(T : bool);
> }
> 
> I could be missing something, but this effectively declares an opCast!bool
> operator.
> 

opCast means explicit cast, as in cast(bool)regexMatch or !regexMatch or regexMatch && 2.

> http://www.d-programming-language.org/operatoroverloading.html#Cast claims that
> both ! and bare references will get rewritten to opCast!bool:
> 
>   if (e)   =>  if (e.opCast!(bool))
>   if (!e)  =>  if (!e.opCast!(bool))
> 
> That should take care of the return, no?

That only works for conditions and arguments to boolean operators. If you think it should also work for return values where the enclosing function is declared to return bool, then that is an enhancement request. It might be a reasonable one.

> 
> Note that the same compile failure happens if I write:
> 
>   auto re = regex("test");
>   if (match("test", re)) { ... }
> 

Works for me.

> 
> It strikes me that the language docs are rather sparse on defining what can and
> cannot be implicitly converted.

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Neither int (outside the range [0,1]) nor RegexMatch implicitly convert to
> > > bool. Negating counts as an explicit cast to bool.
> > 
> opCast means explicit cast, as in cast(bool)regexMatch or !regexMatch or
> regexMatch && 2.

I think this is the crux of what we're arguing about.  To me, explicit casting happens when you write cast(T) in the code.  When the compiler generates a cast for you, that's implicit casting.

Is this not correct?

It seems to me that opCast is pretty useless unless the compiler can decide to use it to convert an object for you.

> > http://www.d-programming-language.org/operatoroverloading.html#Cast claims that
> > both ! and bare references will get rewritten to opCast!bool:
> > 
> >   if (e)   =>  if (e.opCast!(bool))
> >   if (!e)  =>  if (!e.opCast!(bool))
> > 
> > That should take care of the return, no?
> 
> That only works for conditions and arguments to boolean operators. If you think
> it should also work for return values where the enclosing function is declared
> to return bool, then that is an enhancement request. It might be a reasonable
> one.

Why should it only work in those cases?  I can't find anything in the language docs that says this.  The docs on functions say that when a type is passed in, implicit conversion is used as one of the match possibilities.  That's opCast, no?  So if parameter passing is using opCast for implicit conversion, the return statement should be too.  Hence my labeling this as a bug.

> > Note that the same compile failure happens if I write:
> > 
> >   auto re = regex("test");
> >   if (match("test", re)) { ... }
> > 
> 
> Works for me.

My mistake - this case does work.

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > (In reply to comment #4)
> > > > Neither int (outside the range [0,1]) nor RegexMatch implicitly convert to
> > > > bool. Negating counts as an explicit cast to bool.
> > > 
> > opCast means explicit cast, as in cast(bool)regexMatch or !regexMatch or
> > regexMatch && 2.
> 
> I think this is the crux of what we're arguing about.  To me, explicit casting
> happens when you write cast(T) in the code.  When the compiler generates a cast
> for you, that's implicit casting.
> 
> Is this not correct?

In D, cast(T) is an explicit cast as is using an object in a boolean context such as if(...) !... ...||... ...&&... etc. Those are presumably the cases referred to on the Operator Overloading page.

> 
> It seems to me that opCast is pretty useless unless the compiler can decide to
> use it to convert an object for you.
> 

It cannot, except in the cases where it inserts cast(bool).

> > > http://www.d-programming-language.org/operatoroverloading.html#Cast claims that
> > > both ! and bare references will get rewritten to opCast!bool:
> > > 
> > >   if (e)   =>  if (e.opCast!(bool))
> > >   if (!e)  =>  if (!e.opCast!(bool))
> > > 
> > > That should take care of the return, no?
> > 
> > That only works for conditions and arguments to boolean operators. If you think
> > it should also work for return values where the enclosing function is declared
> > to return bool, then that is an enhancement request. It might be a reasonable
> > one.
> 
> Why should it only work in those cases? 

It is about disabling some narrowing implicit conversions to bool while still allowing them were it really makes sense.

bool b = 2; // error, int does not implicitly convert to bool
if(2){...} // fine, because explicit cast(bool)2 works.

> I can't find anything in the language docs that says this. 
> The docs on functions say that when a type is passed in,
> implicit conversion is used as one of the match possibilities.  That's opCast,
> no? 

No. opCast cannot be used for implicit conversions. At some point there was even the idea of introducing opImplicitCast.

> So if parameter passing is using opCast for implicit conversion, the
> return statement should be too.  Hence my labeling this as a bug.
> 

Parameter passing does _not_ use opCast for implicit conversions.

The title is plain wrong and there is nothing to do about it save for changing the compiler/language. Closing as wontfix.