Based on recent report of Simon, I did a short test:
type
OP = ptr O
O = object
i: int
proc int(o: OP): int =
0
var j: int
var k: int8 = 0
j = int(k)
nim c t.nim Hint: used config file '/home/stefan/Nim/config/nim.cfg' [Conf] Hint: system [Processing] Hint: t [Processing] t.nim(12, 9) Error: type mismatch: got (int8) but expected one of: proc int(o: OP): int nim -v Nim Compiler Version 0.14.3 (2016-08-30) [Linux: amd64] Copyright (c) 2006-2016 by Andreas Rumpf
Where would the compiler bug be?
You define a proc named int, so when encountering int(k), the compiler tries to call this proc instead of doing a type conversion. I'd say, it behaves as expected.
Since types are not keywords in Nim, it is not per se illegal to name a proc int.
I would have expected that the compiler sees that the proc parameter does not match and so ignores that proc and assumes that a type conversion is intended.
My initial guess was, that the compiler may simple confuse "ptr object" and "int". But same error with other proc parameters. So defining a proc with name of a type shadows the already defined type conversions. Well, I do not know how type conversions are handled internally, for me type conversions may work like predefined procs for that conversion. And I do not expect that defining new procs with different parameters shadow other procs with same name.
If this behaviour is really intended, then the compiler should give a warning, or better an error when such name conflicts occur. (There may exist many of these in the GTK3 related wrappers -- have no idea how to discover all that systematically.)
I agree that it would be able to determine wether this is a proc call or a type conversion from the parameter type. This can be a feature request.
It is probably not so simple to issue a warning with such conflicts, because the type may be defined in one module, the proc in another module, and both get imported to a third module.