On 07/10/2013 04:10 PM, bearophile wrote:
> Ali Çehreli:
>
>> Change the code so that the result does not fit a ubyte you will get
>> the same error as in line 11.
>
> The result is supposed to fit in an ubyte because the input is supposed
> to be made of nibbles.
Not in either of the two cases that I have given:
a) (1 << 8) would not fit a ubyte
b) (42 << 4) would not fit a ubyte
Of course we are reminded again that even if 1 and 42 are ubytes, the
result of the << operator is int.
So you first expression (1 << 4) is an int which happens to fit a ubyte
and that line compiles.
> (I have tried to add asserts or tests, but they
> don't change the situation, so I have omitted them here).
>
>
>> That foreach is a runtime foreach because it is applied on 'result' as
>> opposed to the type tuple 's'. Apparently the compiler does not do
>> that kind of code analysis.
>
> Right, but is it right to ask for such analysis to be performed?
That would be great but there are many other cases where the compiler
does not do anything like that. Here, it would have to decide similar to
"even though this is a runtime foreach, I know at compile time that
'result' is a fixed-length array so 'i' is between 0 and 10. I also have
this compile-time tuple template parameters. Now let me see whether
running that code would produce values that would fit the 'result's type
ubyte."
I don't think we are there yet. :)
>
> Bye,
> bearophile
Ali
