> Changing it to 0'i8 fixes the problem (it's surprising to me that the type > suffixes are different from the types they denote).
You can imitate it by `0.int8`, it's compile-time converted. > So that leaves me with the question of why the 0 literal as the first element > of the tuple was not converted to int8? Because compiler doesn't treat it as a separate value, instead checks type compatibility for the whole l-value and r-value, i.e. of the type of the variable (`result`) and the type of the value you assign to it, two tuples. The manual has an excelent section on [type relations](https://nim-lang.org/docs/manual.html#type-relations). Shortly: [Assignment compatibility](https://nim-lang.org/docs/manual.html#type-relations-assignment-compatibility) requires types be implicitly convertible (and missing there, equal types are assignment-compatible of coarse too). [isImplicitlyConvertible](https://nim-lang.org/docs/manual.html#type-relations-convertible-relation) says about number conversions, nothing about tuples. So, by the manual, they should not be implicitly converted. Even not explicitly (the next code block).
