Hi Andreas,

I've run into a small problem with the latest WIP version of AngelScript. The problematic line of code reads as follows:

ent.renderfx = RF_MINLIGHT | RF_WEAPONMODEL | RF_FORCENOLOD | ( cg_shadows.integer < 2 ? RF_NOSHADOW : 0 );

And the error is:

^1ERROR: D:/Projects/rapid/game/base/progs/client/main/vweapon.as 326:98: Can't implicitly convert from 'int' to 'cg_entrenderfx_e'.^1
^1ERROR: D:/Projects/rapid/game/base/progs/client/main/vweapon.as 326:73: Both expressions must have the same type

ent.renderfx is an int and all RF_ constants are cg_entrenderfx_e enums. Now to workaround the problem I have to explicitly convert RF_NOSHADOW to int, which seems a bit weird because AS should have no trouble converting enums to int, at least it works with simpe assignments without any hassle. Does the ternary operator which mixes ints and enums need some special handling in the compiler, perhaps?

Thanks.

Ternary operator type conversion rules and implicit conversions create problems in C++ all the time, in some cases making unsafe conversions without issuing a warning. If Angelscript decided to have a more strict set of rules, I completely endorse their decision. Just write a cast to be explicit about what your code means to do.

Here's an example:

#include <iostream>

struct Wrapper {
  double x;
  operator double() const { return x; }
};

Wrapper g() {
  return Wrapper{5.2};
}

double f(bool b) {
  return b ? 0 : g();
}

int main() {
  std::cout << f(false) << '\n'; // <-- Prints 5!
}

or make sure that all your returns are the same type i.e. double in this case:

return b ? 0.0 : g(); // change 0 to 0.0, then your output prints 5.2

Fun and games ?

I know AngelScript follows C++ rather closely at times but that doesn't necessraily mean it shouldn't avoid its pitfalls. Programming language doesn't have to be a nuisance to the programmer unless it's strictly necessary.

If there are implicit conversion rules between enum and int already in place, I see no reason not to follow them in the case of ternary operator.

@_vicious_ I'll look into this. I agree with you that in this case the compiler could probably safely do an implicit conversion to int.

I've change this now so that the expressions in the ternary condition can be implicitly converted to the common type. The compiler will convert the expression that costs less to convert, using the same principles as what is used to match arguments when looking for best function overload to call.

This change is available in revision 2718.

Awesome! Thank you very much ?