You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
typeFoo=object
output, input: uint16
z: uint16var x =Foo(input: 100, z: 1000)
echo x # (output: 0, input: 100, z: 1000)swapEndian(x.output, x.input)
echo x # (output: 0, input: 0, z: 771) # z was modified under the hood! the compiler didn't complain about implicit conversion from var uint16 to var uint64
If we used a proc instead of a template, the compiler would (correctly) complain: Error: for a 'var' type a variable needs to be passed; but 'uint64(x.output)' is immutable
Example1
templaterunTest[T](a, b: T) =static:
const s =$T
echo ($T, $type(a), $type(b))
procmain()=var a: intvar b: int32static: echo"trying (int,int32):"runTest(a, b)
var c: floatstatic: echo"trying float:"runTest(c, c)
main()
Current Output
trying (int,int32):
("9223372036854775807", "int", "int32")
trying float:
/Users/timothee/git_clone/nim/Nim_devel/compiler/lineinfos.nim(229) raiseRecoverableError
Error: unhandled exception: cannot extract number from invalid AST node [ERecoverableError]
there's a few bugs here:
$T shows as 9223372036854775807 in 1st example (int)
$T crashes compiler in 2nd example (float)
the type of template parameters is only used during signature matching (ie, the compiler just checks that types can match modulo implicit conversions) but somehow is lost when template is called:
in example above, a, b: T should have same type T but their types are actually int and int32
Example2
in this example the signature matching itself should fail. Contrary to previous example, the bug happens during signature matching, which should fail (ie, not implicit conversion possible bc of var), but doesn't
# proc runTest[T](a: var T, b: var T) = # this would (correctly) give Error: ... 'float64(b)' is immutabletemplaterunTest[T](a: var T, b: var T) =echo (cast[int](addr a), cast[int](addr b))
b = a
procmain()=var a: float64=3.14var b: float32=1.42runTest(a, b)
echo (a,b)
main()
output:
# should give CT error instead of compiling/running
(140732816759008, 140732816759004)
(3.14, 3.140000104904175) # doesn't actually matter, just that it shouldn't compile
The problem here is that var T parameter passing makes no sense for template, template can always mutate due to its inlining semantics. IMO var T for parameters in templates should be deprecated.
type checking for templates doesn't work the same as for procs, causing bugs
Example0
can anyone spot the bug in
swapEndian
?despite looking type safe, it isn't so:
If we used a proc instead of a template, the compiler would (correctly) complain:
Error: for a 'var' type a variable needs to be passed; but 'uint64(x.output)' is immutable
Example1
Current Output
there's a few bugs here:
$T
shows as9223372036854775807
in 1st example (int)$T
crashes compiler in 2nd example (float)in example above,
a, b: T
should have same type T but their types are actually int and int32Example2
in this example the signature matching itself should fail. Contrary to previous example, the bug happens during signature matching, which should fail (ie, not implicit conversion possible bc of
var
), but doesn'toutput:
[EDIT]
related issues
Additional Information
Your Nim version (output of
nim -v
).latest devel f50e450
Was it working in the previous Nim releases?
no
The text was updated successfully, but these errors were encountered: