> I think avoiding numeric types is a good decision. It tends to eventually cause problems when one implementation (...) It seems you're mixing up the language

> I think avoiding numeric types is a good decision. It tends to eventually cause problems when one implementation (...) It seems you're mixing up the language definition with implementations that try to follow the language definition. If different implementations have different results then either they are buggy or the language has some important holes in the specification. Either way,the solution to this problem is not less validation. > One should remember that any sane application will be parsing the config file into internal data structures and validating it anyway so it gets little benefit from the numbers being already “parsed”. That's the whole point, isn't it? I mean, if you already acknowledge the fact that this parsing and validation is a basic requirement, why handle it as an afterthought and force developers to add their own hand-rollef absurd and unnecessary type checks and type coversions? Wouldn't it simply easier to let the language and the parser do that already? I mean, no one ever complained that JSON had string types. In fact, one of JSON's main complaints is that it doesn't support enough types, such as timestamps.