Tcl_ConvertToType, a function in the Tcl C API, converts a value from one type to another, if possible.

KBK said the following in the Tcl Chatroom, 2014-06-19:

The problem with Tcl_ConvertToType isn't performance. It's future-proofing. There was a lot of code out there that assumed it could Tcl_ConvertToType to force the object {12345678901234567890} to a double, leaving a 'double' internal rep. In the 8.4/8.5 reworkings of numeric handling, we introduced first 64-bit ints and then arbitrary-precision ints... and suddenly, it was much more convenient to leave numbers in a 'canonical' form and have Tcl_GetFooFromObj do the casting. Otherwise, we had repeated string conversions, because we couldn't just cast the double {123456678901234567890} back to an integer; it lost precision. So we adopted the rule that the 'internal rep' belongs to whatever code creates it; others are expected to Tcl_GetWhateverFromObj to extract it. And, if it can happen to something as simple as integers, it can happen to anything.

APN I am not sure that statement "So we adopted...creates it" is stated clearly. If you create a string or an integer and call a list function on it, the internal rep will happily get shimmered to a list intrep even though the list code did not create the Tcl_Obj. Expected and correct behaviour. What I believe that statement meant to say was that the caller of Tcl_ConvertToType should not expect that the call would have shimmered the intrep to the desired type. It may be unchanged, changed to the desired type or changed to different type (e.g. you might want it changed to a bigint but it gets changed to int because it fits in 32 bits).