@LeuGim Thanks -- you got me focused on the first element of the tuple when I
thought the issue was the second (the compiler message is ambiguous, since both
types are different in the 'got' and 'expected' parts of the message).
I checked the language manual and the section on "Numerical constants" says
"Literals without a type suffix are of an integer type, unless the literal
contains a dot or E|e in which case it is of type float.". So the 0 I wrote is
of type 'int'. Changing it to 0'i8 fixes the problem (it's surprising to me
that the type suffixes are different from the types they denote). But changing
this to
let zero:int8 = 0
return (zero, @[])
Run
also works (compiles without error). Which led me to the manual section on
Pre-defined integer types:
[https://nim-lang.org/docs/manual.html#statements-and-expressions-type-conversions](https://nim-lang.org/docs/manual.html#statements-and-expressions-type-conversions)
This says that only widening conversions are implicit (and then in the
immediately following table of examples, it says that
myInt16 + 34 # of type ``int16``
Run
; I don't understand this; 34 is of type int, which is wider than int16, so why
isn't the type of this expression int?)
But it then goes on to say that narrowing conversions are 'implicit' under
certain circumstances, which are met by my case, as demonstrated by the
assignment of 0 to zero (which narrows an int to an int8). So that leaves me
with the question of why the 0 literal as the first element of the tuple was
not converted to int8? As was apparently the case with the previous version of
the compiler?
