I'm writing a script type like std::optional<T>. I've seen the document saying that the bool opImplConv() won't be used because of ambiguity. But I think it can use bool opConv() to convert the result of expression to bool. The if statement itself is enough to consider the user needs a explicit conversion. This is exactly how C++ deal with non-bool result in a if condition, it will invoke the operator bool() of that type even if it is declared as explicit operator bool().

If this feature can be implemented, I can write script like this

optional<string> opt_str = "test";
if(opt_str)
	// ...

instead of

optional<string> opt_str = "test";
if(bool(opt_str))
	// ...

HenryAWE said:

optional<string> opt_str = "test";
if(opt_str)
	// ...

What would the result for that be? “test” is neither true nor false 🙂

I will eventually get to implementing an engine property to allow the application to set whether or not conversion to bool should be done implicitly. It is not a high priority for me though.

Should someone (*hint*) provide the patch for it I'd gladly incorporate it into the repository though.

Maybe the code fragment above is not clear. The optional manages a value that may or may not exists (Introduction of the optional in C++17). For example, it is useful to implement a optional<T> find(const string&in key) method of a dictionary-like object. The optional can be converted to bool to check if the optional contains value. Here is a detailed script example:

optional<int> empty_opt;
if(empty_opt) // `bool(empty_opt)` or `empty_opt.has_value()` in current version of AS
    do_something(empty_opt.value); // Won't be executed
    
optional<int> non_empty_opt = 42;
if(non_empty_opt)
    do_something(non_empty_opt.value); // Will be executed

WitchLord said:

Should someone (*hint*) provide the patch for it I'd gladly incorporate it into the repository though.

After a glance at the source code of AS, I guess this behavior is controlled by the asCCompiler::CompileIfStatement in source/as_compiler.cpp. Maybe I can try to implement something like a engine property named asEP_EXPLICIT_BOOL_CONV_IN_CONDITION?

Give it a shot. 🙂

I can make the final adjustments if needed.

If I understand the code correctly, the only modification needs to be done inside the asCCompiler::CompileIfStatement is changing the 4th argument of ImplicitConversion from asIC_IMPLICIT_CAST to asIC_EXPLICIT_VAL_CAST if a certain engine property is set. I've walked through the source of asCCompiler::ImplicitConvObjectToPrimitive, and it seems that this function can also perform an explicit cast if a correct convType argument is passed. (The function name is quite confusing 😂)

If the above approach is correct, I will try to implement the engine property and corresponding test in this way.

In addition, how do I summit a patch? Should I just post (probably lengthy) svn diff result here, or send it by e-mail or something else?

You can send me the modified files via email. Either diff or complete files is ok, though I prefer the complete files.

Don't forget to provide the code for testing the changes as well, so I can merge that into the regression test suite.

@WitchLord The patch has been sent by email.

I've incorporated your patch into the WIP version now.

https://sourceforge.net/p/angelscript/code/2964/

I opted for a different name for the engine property: asEP_BOOL_CONVERSION_MODE, as I may extend it for other changes too in the future.

I also added the contextual conversion to bool for loop statements (while, do-while, for), ternary condition operator, and boolean operators (not, and, or, xor).

Observe, if the expression that is converted to bool is for an object handle and the handle is null, there will be a “Null pointer access” script exception at runtime when the opConv is called on the null handle.