The conditionals in CQL currently allow the cases of the conditional to be of a different type.  E.g., this is valid:

if Count(list) = 0 then
  false
else
  list

The type of this statement would be Choice<boolean,List<T>>. This is quite unusual, as most languages having an `if` as an expression require both types to be compatible. There are good reasons for this: most of the time having different types in an expression like this is unintentional, and should be caught by the compiler.

The reason CQL currently uses these semantics is that is enables writing a ToValue(value Choice<a,b,c>) function that returns, either a or a Choice<b,c>. This sounds exotic, and it is, but is actually quite useful to track allowed types in the common situation where the logic uses FHIR choice types (e.g. Observation.value), and you want a friendly way to get to the (primitive) value.

However, I wonder whether the usefulness of this feature outweighs the fact that this opens up the type system to a point where it will not catch the common error I described above.

I can see two solutions that would allow us to have our cake and eat it:

• Do not allow this, unless the function that requires this construct (like ToValue) has some annotation `@multi-type-if` (or any better name).
• Emit a warning, and have a config file/flag/annotation for the compiler to suppress the warning.

Speaking to Bryn about this, it seems the first solution is the easiest to implement, although I think the second one might be useful in future scenarios (as it is common in other compiler).