Consider type promotion rules for select

[dsharletg]

Currently, select requires the second and third arguments to have a matching type.

It might make sense to allow some type promotion, e.g. select(condition, uint16_buf(x, y), uint8_buf(x, y)) would transparently cast the uint8 value to uint16.

One upside is it makes the language less pedantic/verbose in cases where casts are needed today. One downside is it may enable silent performance bugs that otherwise would have been caught. There may be other things to consider too.

[ashishUthama]

One of the most common bugs we encounter are folks accidentally ending up with double precision math instead of single. Its trivial to catch by looking at the html output, but newcomers often seem to do this unwittingly due to arithmetic type promotion rules.

Just adding weight to the downside you mention. Reducing such unintended promotions might be worth the verbosity of the casts.

[abadams]

Do you have an example of a piece of code that's unintentionally double-precision? I thought we made it pretty hard to do that.

[ashishUthama]

The most common case (perhaps only) I noticed was forgetting to add the f in x.xxf literals.
When working with uint8s and wanting to do single precision compute there is always a final cast back to uint8, so forgetting to add that 'f' in any one literal makes the corresponding code switch to double precision math.
This usually happens when we naively copy the initial double precision code to create a single precision version which uses the fast_* functions.

[shoaibkamil]

Hm, that's odd. I though Halide's Expr constructor didn't do that conversion, i.e. Expr(1.0) will give an error.

[abadams]

Expr(1.0) won't give an error, but some_float_expr + 1.0 will. You can only construct an Expr from a double with the explicit constructor.