> 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).
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
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_... 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.
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
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
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_... 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.