Nim v2: get rid of style insensitivity

[dom96]

Nim v2 is on the horizon which presents a unique backwards compatibility opportunity. The original plan for v2 was to simply change the gc to be orc by default but I think we can be more ambitious.

So I am proposing we get rid of style insensitivity in Nim for version 2 and make Nim fully case sensitive.

Not because style insensitivity leads to bugs or any of the other things that those unfamiliar with Nim hypothesise but because it is one of the main reasons that people do not even try Nim. At the end of the day we want Nim to grow and this seems like a good way to do it. It's a fairly easy change too (in the compiler at least) and should reduce the perception folks have about Nim being error prone because identifiers can be mistaken.

Thoughts welcome. Before responding be sure to familiarise yourself with exactly how style insensitivity works in Nim, including the fact that Nim already ships with a --styleCheck option which allows developers to opt-in their code to be case sensitive. For more info read this comment.

I honestly don't think that we should remove a useful language feature because a few people on HN complain that it makes Nim "error-prone" which it actually doesn't. It's actually the opposite: having case insensitivity means that you can't mix is_ok with isOk. If they have an agressive stance towards Nim from the start, they won't magically start using it if we'd remove case insensitivity.

[Araq]

I don't care much either way. I'm slightly in favor of removing it if we at the same time have the tooling enforce nep1 in the hope it makes Nim simpler to teach and to (re-)implement.

[dom96]

The biggest loss I think for me would be the ability to create wrappers with snake_case and use them with camelCase. But thinking about it we could create a couple macros that generate an alias for the other case variant to keep this use case in place and still get a case sensitive language.

[EyeCon]

I'm very fond of style insensitivity. I agree with @Yardanico that not being able to simultaneously have is_ok and isOK a good thing.

I don't know if the argument for having (maybe) better acceptance and having it somewhat easier for the tooling (because then they can just do a string match) is worth removing a feature.

[RSDuck]

I'm for it, mostly because of problems with C libraries.

One example would be OpenGL having enums such as GL_FLOAT, but also a type called GLFloat. Which in the official OpenGL wrapper is solved by naming one cGL_FLOAT, which is ok, but not nice.

Another example is in a library which has a NvColorFormat_V8_U8 and NvColorFormat_V8U8 constant. At first glance having both of these constants looks stupid, but there is actually a logic behind this (thanks Nvidia) and I think in some cases like this the underscore does carry a meaning.

[deech]

I respectfully disagree that it is a good feature and it has bitten me multiple times, an example where it caused problems in the very area it was trying to help ( FFI wrappers ) was when I had to wrap a C identifier that ended with an underscore, the following fails with Error: invalid token: trailing underscore:

type A_ {.importc: "A_".} = object

The same goes for valid C identifiers like A__blah.

[deech]

Further the insensitivity extends to language keywords, there's no reason for all of proc, pRoc and p_r_OC to be valid.

@deech that's true for most keywords, but what about isnot vs is_not and similar?

[deech]

I'm fine with either but not both.

[dom96]

From planetis (sorry, moving that from the forum thread here to avoid splitting the discussion):

Please leave style insensitivity alone, this is not in any way, an "ambitious" change. Btw did you know you can send an email to user.name@gmail.com with a point anywhere between username and it would still work? My point is, it's not that uncommon.

[foderking]

I agree. remove it!
Also, it would be great if the compiler's errors could be improved and more specific
I have wasted a lot of time on decrypting errors

[bluenote10]

I don't have a strong opinion, but it could help if it wasn't the first thing that comes to mind when people start talking about Nim. A random example:

Nim's style insensitivity is definitely one of the most controversial points of that language, and many people see it as a "billion dollar mistake" (myself included) 🙂

[SolitudeSF]

what about adding pragma to force style sensitivity on some symbols?

[planetis-m]

Meanwhile in raylib#bindings-dev a developer that works on R bindings posted:

FYI - I've made aliases to all functions, so you can use either snake_case or TitleCase. It is auto-generated with some regex magic so no hassle 🙂

To me, problems when wrapping foreign libs are related to them having bad naming conventions and are not in line with Nim's NEP1, anyway.