We can turn it anyway we like but we must not go against the vital rule that a 
compiler must not ever change an identifier behind the developers back.

leading '_' can be discussed (I'm pro but can accept Nim staying against it).

Case sensitivity and/or rules (like types capital 1st. letter, vars and procs 
not) can be discussed/voted on/dictated by Araq, .... One might not like the 
outcome but one can live with it.

"Style insensitivity", however, goes against the vital rule. Simple as that. 
Even a "religious" preference like CamelCase over snake_case is something that 
one may live with if that preference would be important enough to @Araq and the 
core team to ban underscores.

But the "style insensitivity" was a major sin from the start. Period.

If Araq hates snake_case so much he should simply forbid it (i.e. any 
underscores in any identifiers). But allowing them and even dressing it up as 
"liberal" and cool feature - but then having the compiler change identifiers 
and un-snake_case them is a major sin and frankly not acceptable for a good 
language that is concerned with safety and clarity - even more so when a 
language produces code in other languages.

If I wanted to play lottery with the compiler I could have stayed with C.

Reply via email to