4 ms·

Go does not. It doesn't do any magic conversion. If you want to use different types together, you need to cast one of them, period. Why C/C++ ever thought this

Go does not. It doesn't do any magic conversion. If you want to use different types together, you need to cast one of them, period. Why C/C++ ever thought this was a good idea is beyond me. The whole point of strong typing to me, is that you should never be wondering what type something is. C thought they were adding convenience, but decades have shown that it only adds bugs, and forces people to memorize weird rules, or remember to use the right compiler warnings. Good riddance.

kqr 5y ago
Ada, the original "better C", similarly does not.
wahern 5y ago
> Why C/C++ ever thought this was a good idea is beyond me. Because C was evolved from BCPL, an untyped language, over the course of about 10 years, and then 10 more if you include refinements for what became ANSI C (C89). And at every iteration one of the concerns was maximizing source and binary compatibility with previous iterations; it was always actually being used in other projects rather than being developed to completion in a sandbox. In transitioning to stronger typing, most of the attention seems to have been spent on improving treatment of pointers and aggregate types (arrays, structs, etc). There's a well known history of C, including design motivations, published by Dennis Ritchie in 1993: "The Development of the C Language", https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html They were well aware of various other languages, the pros and cons of how they handled typing, and they actually had (and developed) quite strong opinions. See, for example, this 1981 note by Kernighan, "Why Pascal is Not My Favorite Programming Language", http://www.lysator.liu.se/c/bwk-on-pascal.html http://www.lysator.liu.se/c/bwk-on-pascal.html And checkout this 1979, third-party comparison of C and Pascal by Prabhaker Mateti, "Pascal Versus C: A Subjective Comparison", https://link.springer.com/content/pdf/10.1007/3-540-09745-7_3.pdf https://link.springer.com/content/pdf/10.1007/3-540-09745-7_... Early on the author establishes a basic, still familiar measure: "One of the most important factors in choosing a language for a project should be the estimated debugging and maintenance costs." One of the points in fleshing that out is, "Permissive type checking should be outlawed." But see the two adjacent points in that section--"Simple things that could be done mechanically, without spending much thought, should be done by a program." and "It is dangerous to use our knowledge of the internal representation, as chosen by a compiler, of a data type."--and consider how they might relate to arithmetic conversions.
edflsafoiewq 5y ago
C has model of a machine where there's a bunch of ALUs that operate on homogeneous types of size >= int. So int x int -> int, uint x uint -> uint, etc. So an op first converts its arguments to a common type of the smallest necessary size, then sends them into the appropriate ALU.

kqr 5y ago

Ada, the original "better C", similarly does not.

wahern 5y ago

> Why C/C++ ever thought this was a good idea is beyond me. Because C was evolved from BCPL, an untyped language, over the course of about 10 years, and then 10 more if you include refinements for what became ANSI C (C89). And at every iteration one of the concerns was maximizing source and binary compatibility with previous iterations; it was always actually being used in other projects rather than being developed to completion in a sandbox. In transitioning to stronger typing, most of the attention seems to have been spent on improving treatment of pointers and aggregate types (arrays, structs, etc). There's a well known history of C, including design motivations, published by Dennis Ritchie in 1993: "The Development of the C Language", https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html They were well aware of various other languages, the pros and cons of how they handled typing, and they actually had (and developed) quite strong opinions. See, for example, this 1981 note by Kernighan, "Why Pascal is Not My Favorite Programming Language", http://www.lysator.liu.se/c/bwk-on-pascal.html http://www.lysator.liu.se/c/bwk-on-pascal.html And checkout this 1979, third-party comparison of C and Pascal by Prabhaker Mateti, "Pascal Versus C: A Subjective Comparison", https://link.springer.com/content/pdf/10.1007/3-540-09745-7_3.pdf https://link.springer.com/content/pdf/10.1007/3-540-09745-7_... Early on the author establishes a basic, still familiar measure: "One of the most important factors in choosing a language for a project should be the estimated debugging and maintenance costs." One of the points in fleshing that out is, "Permissive type checking should be outlawed." But see the two adjacent points in that section--"Simple things that could be done mechanically, without spending much thought, should be done by a program." and "It is dangerous to use our knowledge of the internal representation, as chosen by a compiler, of a data type."--and consider how they might relate to arithmetic conversions.

edflsafoiewq 5y ago

C has model of a machine where there's a bunch of ALUs that operate on homogeneous types of size >= int. So int x int -> int, uint x uint -> uint, etc. So an op first converts its arguments to a common type of the smallest necessary size, then sends them into the appropriate ALU.