it makes sense to provide an extension implicit boolean conversion operator for string. the compiler looks for implicit conversions for conditional blocks.

Yup, makes sense but do you mean we should provide that extension as default in boo?

Also considering this is a light change for a very common case I think we should optimize it and wire it directly as we do for the other 'primitives' (to avoid a slight performance hit wrt extension method redirection and make generated assembly more friendly to static analysis [null reference tracking etc]).
Makes sense?

This must works for ducks of course:

foo as duck = string.Empty
print "oops" if foo

Implementing this for conditional expressions (if/else) is quite simple, however I am not sure what to do with expressions such as:

x = "x"
y = "y"
print x or y #prints "x" (a string, not a boolean)

Currently this 'inline binary expression' causes a change of semantic when there is an implicit boolean conversion extension as in:

[extension]
def op_Implicit(s as string) as bool:
    return not string.IsNullOrEmpty(s)

x = "x"
y = "y"
print x or y #prints True (a boolean not a string)

but of course same problem would apply not only for string but for any type with an implicit boolean conversion.

Also, interestingly the following works though I guess it should not be allowed:

x = "x"
y = "y"
print x and y #prints "y" (why not "x"?)

Both 'or' and 'and' are short circuited operators that return the last evaluated operand. From that follows that ("x" and "y") should return "y".

op_Implicit should only be used to evaluate the operand trueness. The fact that's also being used as the resulting value is a bug.

Fixed in rev. 3199