> please keep discussion around _style insensitivity_ in the RFC Sorry, I am not the first one to broke this rule.
I had to read twice the code to understand where was the error, since I did incorrectly read SDL_QUIT. The problem does not lie in style sensitivity here. I present how it could be detected with and without case insensitivity: -> with case insensitivity: One variable would be overwritten by the other. If the compiler detects the conflict, fine, the developer can rewrite one of the two variable. The user would have two different variable names. Easy. -> with case sensitivity: the problem relies on type checking: Why does the compiler does not warn about an equality between variables of different types ? Since SDL_Quit is a function, it is trivially always different from an enum type. While we may permit trivial loops, I am surprised the C compiler does not emit a warning. > There has been a lot of discussion about it and there don't seem to be many > arguments for disabling it other than “I don't have good feelings about it” > or “I really want to have foo_bar and fooBar refer to different things” No. there have been better arguments like problems with FFI. This discussion: <https://github.com/nim-lang/RFCs/issues/456> lead to improvement of the --styleCheck option if I am not mistaken. Why do we keep posting in this thread, when we agree to not have breaking changes ? Should we not lock this thread ? @Araq mentioned in the 2022 NimConf that he does not want to have stupid "print with parentheses" change breaking all Nim codebases.
