lizmat it shouldn't 06:42
m: my num $a = 42
camelia ===SORRY!=== Error while compiling <tmp>
Cannot assign a literal of type Int (42) to a native variable ($a) of
type num. You can declare the variable to be of type Real, or try to
coerce the value with 42.Num or Num(42).
at <tmp>:1
------> m…
08:42 finanalyst left 10:51 guifa_ left, guifa joined
ugexe Then why does the first example work 12:43
lizmat m: my int $a = 42; my num $b = $a; dd $b 12:48
camelia 42e0
lizmat native values auto-coerce
m: my int $a = 42; my str $b = $a; dd $b
camelia "42"
lizmat I guess the problem is that even though we have a --> int in the signature, the codegen of the call upgrades the value to Int nonetheless :-( 12:49
13:25 librasteve_ joined 15:35 librasteve_ left
lizmat ugexe: also, it looks like the optimizer makes that work: 15:52
$ raku --optimize=off -e 'my int $a = 42; my num $b = $a * $a; say $b'
This type cannot unbox to a native number: P6opaque, Int
ugexe right 15:53
lizmat the optimizer changes that to an nqp::mul_i
ugexe i actually have a branch that fixes that example. which led me to implement constant folding. which means i have to implement an optimization stage to put it in
github.com/rakudo/rakudo/blob/e78c...lain=1#L29 i guess we are here 16:18
although blin the ecosystem should probably be above that 16:19
lizmat yeah...
but still!
16:53 sjn left 18:56 librasteve_ joined 21:34 Geth left 21:55 RakuIRCLogger left 22:31 Geth joined