Dredd mutation introduces ambiguity in conditional expression resultant type

[JonathanFoo0523]

Applying dredd to

struct foo {
  foo(int) {};
  operator int();
};
enum baz { bar };

int main() { 
    0 ? foo(0) : baz::bar;
}

produce

struct foo {
  foo(int) {};
  operator int();
};
enum baz { bar };

int main() { 
    if (!__dredd_enabled_mutation(5)) { __dredd_replace_expr_bool_false(0, 0) ? foo(__dredd_replace_expr_int_zero(0, 1)) : __dredd_replace_expr_int_zero(baz::bar, 3); }
}

which results in compilation error:

conditional expression is ambiguous; 'foo' can be converted to 'int' and vice versa

[afd]

Interestingly, this does not compile (for the same reasons that the mutated version does not compile):

struct foo {
  foo(int) {};
  operator int();
};
enum baz { bar };

int main() { 
    0 ? foo(0) : 1;
}

I don't understand why the rules for the enum are different.

[JonathanFoo0523]

@afd If I understand it correctly, this issue happens because we are trying to force a type to the enum constant, right?

Instead of not mutating the enum constant, it is possible(and whether it is a good idea) to introduce templated prelude function

template <typename T> 
static T __dredd_replace_expr_int_like_zero(T arg, int local_mutation_id) {
  if (!__dredd_some_mutation_enabled) return arg;
  if (__dredd_enabled_mutation(local_mutation_id + 0)) return 1;
  if (__dredd_enabled_mutation(local_mutation_id + 1)) return -1;
  return arg;
}

and mutate the enum constant to

__dredd_replace_expr_int_like_zero<foo>(baz::bar, 3)

[afd]

@JonathanFoo0523 can you open a new issue recording that there may be a better way to solve this problem, via templates, and then self-assign it? Please reference this issue in the new issue - and also mention the single file test(s) that I created in #267, which capture the problem.