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.

[ghost]

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.

[ghost]

@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) :slightly_smiling_face:

[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.

[levovix0]

1. For me, case insensitivity is the best way to resolve disputes between fans of camelCase and snake_case and to please them both.

2. Creating a wrapper over any library from another language is always a problem and it's strange to take into account such trifles as variable name conflicts. If you want to encode the information in the variable name, maybe you should use strings?

[PhilippMDoerner]

As a user, I am mostly neutral and fine with either. If held at gunpoint, I'm leaning towards slightly in favour of removing it. Since I have no idea how this would impact core devs, I am generally in favour whatever is the least amount of effort/makes their life easier since I kinda depend on them for my language of choice to run as smoothly and stable as possible.

What makes me lean slightly in favour of removing insensitivity are the aforementioned C-interop mentions (which I haven't encountered since I also do not use C libs) and that I tend to favour things being explicit rather than implicit. is_ok and isOk implicitly being the same is slightly worrying to me, but does not really affect my code style: I'm using full camcelcase either way (where my project allows me to anyway).

[dado023]

I will post my conditional opinion here. For me as a beginner programer, style insensitivity is one of good features, which makes it forgiving if i change my style.

However, if style insensitivity is complicating further nim development and interoperability, then it should be removed, if not, then it should stay....simple as that.

[simonkrauter]

Would it be maybe enough to make the feature opt-in?

[exelotl]

I think style insensitivity should stay!

In the last 3-4 years of using Nim I would estimate that I've maybe lost 1 hour to style insensitivity.

• One time when I was making a C wrapper (luckily the conflicting definitions were "legacy" anyways so I could just remove them when I realised what was happening)

• Another time I defined a parameterless template scorebar with technically the same name as a module score_bar.nim, which caused Nim to give confusing messages such as "Error: type mismatch: got <void, Scorebar>". But the root problem is a poor interaction between templates and modules. Style insensitivity just made it possible to trigger it in a way that I didn't expect.

It's harder to quantify the amount of time I've saved thanks to style insensitivity. But I think it helps in a lot of little ways that all add up:

• Scratchpad:

  Consistent style is important, but there are occasions where you legitimately don't care. Debugging macros is a great example: If I want to quickly see what an AST looks like I can write dumptree or echo treerepr foo. My tired fingers appreciate it. I'm going to delete the code 5 seconds later anyway.

• Smoothing over grammatical discrepancies:

  Sometimes I have to use code where the author named their setup function setUp or their tileset tileSet or something else with arguably poor capitalisation. It's nice to not have those choices forced upon you if you disagree with them. This happens with compiler options too, for example --linedir and --stacktrace seem better to me even though they're not the official way.

• Exploration and getting into the zone:

  Related to above - some days I don't know what capitalisation to use myself (should it be scorebar or scoreBar)? Style insensitivity makes it possible to try out both before ideally settling with one, and means I don't have to let my painful indecisiveness stop me from writing code.

  Sometimes I struggle with major productivity issues, so I really do appreciate a language that lets me off the hook in this one case that doesn't make a difference to the correctness of the code itself. In this sense I view style insensitivity as a "well-being" feature, and something that fits right in with Nim's characteristic of letting you get to the heart of the problem domain without distraction.

[ZoomRmc]

... it is one of the main reasons that people do not even try Nim

Citation needed.

Style insensitivity or syntactically significant whitespace are the easiest things to complain about: you don't need to write a single line to start bashing them. However, if such minor quirks prevent you from using a tool which has a potential to solve your problems due to it's technical merits, well, it just means you either don't have enough of a problem or the tools you're already comfortable with is all you need.

At the end of the day we want Nim to grow ...

The main issue of growth is the weak ecosystem. For this Nim needs more developers interested in implementing solid building blocks upon those solid building blocks, provided by the language and the standard library. So, squishing all the bugs, more tests, more docs, finishing already started work, merging or declining all the PRs, unifying and polishing STD's API. That is what's essential to achieve fast and healthy growth, in my opinion.

[AngelEzquerra]

Personally I think it’s not worth the controversy it creates. I think removing it would remove one of the obvious (yet weak) arguments against nim.

Perhaps there is a way to replace the case insensitivity feature with something else that lets us maintain its benefits? All the criticism that I’ve seen of this feature focus on the fact that it cannot be disabled and that it might cause errors due to using two different names for the same symbol. We could add a way to explicitly import a module in a “case insensitive” way, but make it so that all usages of a symbol in the module that imports it must use the same symbol name. I think this fixes the two problems I mentioned earlier (i.e. it’s opt in and there can be no symbol clashes).

An advantage to adding this alternative to the existing case insensitivity is that it would make it easier for people that use case insensitivity to migrate to nim v2.x (which IMHO should be a very important consideration when introducing backwards compatibility breaking changes such as this one).

[FedericoCeratto]

Can I propose a third option? Keep style insensitivity but have the compiler print clear warnings by default when the same element appears with different styles within the same file. The warnings could link to a text explaining how insensitivity is a readability and safety feature, not a bug.

It should have file granularity to support wrappers and the use of 3rd party libraries with different styles. It could be extended to a whole directory or whole project with command line flags.

Edit: I'm aware of the --styleCheck flags and external linters but my point is about doing checks by default, on file granularity and provide a good explanation on the safety and readability benefits. Additionally, --styleCheck enforces camelCase which is not what people necessarily want.

[levovix0]

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

How many people will actually use it? It seems to me that if such checks should be introduced, then in the other tool, not in the compiler.

[ghost]

Can I propose a third option? Keep style insensitivity but have the compiler print clear warnings when the same element appears with different styles within the same file. The warnings could link to a text explaining how insensitivity is a readability and safety feature, not a bug.

(The warning could be disabled with a pragma in library wrappers and so on)

This is already a thing (just a hint instead of a warning, and global to the whole project) - --styleCheck:hint. There is also --styleCheck:error for those who really want to use the original style for the variable throughout their project and all of the libraries.

[ghost]

let isOk = true
echo is_ok

$ nim check --styleCheck:hint test.nim
Hint: used config file 'C:\Nim\config\nim.cfg' [Conf]
Hint: used config file 'C:\Nim\config\config.nims' [Conf]
.........................................................
D:\Projects\NimExperiments\test.nim(3, 6) Hint: 'is_ok' should be: 'isOk' [let declared in D:\Projects\NimExperiments\test.nim(1, 5)] [Name]
Hint: 
26789 lines; 0.160s; 25.586MiB peakmem; proj: D:\Projects\NimExperiments\test.nim; out: unknownOutput

[HugoGranstrom]

Style insensitivity is one of my favourite features of Nim. It is always a pain using other languages and libraries because you are at the mercy of the library developer's code style. One example I'm losing my mind over right now is MPI: MPI_Irec, MPI_Waitall, MPI_Sendrecv_replace.

Having the option to use libraries in my own way is worth gold to me. And regarding those people complaining at Nim using soley that argument, I don't give a dime about what people who clearly haven't put the effort to actually trying the language out thinks. There is nothing stopping a particular user from having the same code convention in their code, so why take it away from those of us who are enjoying it?

[beef331]

Whoops i misread

[xigoi]

Idea: remove style insensitivity, but disallow underscores in identifiers. That way there's no snake_case and it introduces the possibility to use underscores for something else. However, there will still be a problem with things like fooId versus fooID.

(I don't support this myself, but I'd probably prefer it over style insensitivity just being removed.)

[beef331]

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.

Personally this is exactly why I'd want to keep it, machine made Opengl wrappers are full of what i consider stupidly written constants this isnt COBOL we dont needs to scream constants. In my framework I heavily use it to get the Opengl constants to what i prefer which is sane PascalCase instead of SCREAMINGCASE. An _ being important pretty much demonstrates just bad code practices which should not be carried through to a language with a better type system and better language features than the source language imo. We can use templates + typedescs to get around the stupidity that is that API, we do not need to pretend _ is actually important.

[elcritch]

I have a mixed opinion but lean toward keeping it. Mainly due to possible breakage in the ecosystem. Perhaps taking a sampling of projects from Nimble and calculate usage of style invariance to know how much it'd break the ecosystem? If its a lot I'd be concerned it introduce a Py3 situation of old but functional libraries breaking. It might break widely used macros too?

My approach with colleagues has been not mention it, and so far no one has commented on it. It helps that VSCode defaults to style hints being on which helps prevent people being frustrated if they inadvertently run into it.

Perhaps its a matter of the optics? Saying "Nim is case insensitive except for starting letters" is different than saying "Nim is style tolerant". Same thing technically, but it shifts peoples mental model. Defaulting to styleChecks:on and making the documentation and tutorials consistent in calling it "optional style invariance" might reduce it being a hindrance to adopters.

[elcritch]

Alternatively there's a path of keeping style insensitivity, but also tightening up the rules in a few places to reduce common pain points. A few suggestions for that:

• As @deech mentioned keywords really shouldn't be style insensitive. I mean pRoC instead of proc makes me cringe inside whereas is_ok and isOk look like an overshadowing/logic bug if they're different.
• Perhaps extending 'all-caps' constants as another unique set. In C-language family land ALL_CAPS infers constants, wheres AllCaps could be a few things.
• Make module names, like keywords, exempt from style insensitivity to prevent issues like @exelotl's. Or at least make error messages better with modules. Messages like "error cant find typeof(nil)' are opaque to say the least.
• Make style insensitivity configurable per Nimble library (somewhat similar to @AngelEzquerra's suggestion, but no code impact). It is sort of is with config.nims, but I think the local config overrides it? I don't care what a library author chooses, but I don't want to see warnings from their lib based on my projects settings. I only want to see if me or my team is inconsistent.
• Provide a nimble pretty feature that runs nimpretty on the whole (local) project.

Just suggestions, but perhaps a few tweaks to the rules might be an easier path than removing the whole feature.

[xigoi]

Perhaps extending 'all-caps' constants as another unique set. In C-language family land ALL_CAPS infers constants, wheres AllCaps could be a few things.

PLEASE NO. SCREAMING_CASE IS THE WORST. UPPERCASE MEANS “PAY ATTENTION TO THIS”, BUT CONSTANTS ARE PRECISELY WHAT YOU SHOULDN'T PAY MUCH ATTENTION TO. ALSO, AS YOU CAN SEE, IT'S UNREADABLE.

[c-blake]

On a meta-note about the divisiveness - I think it is a sort of human perception thing that feels objective without actually being so..Like the paperwhite monochrome monitors of the 1990s vs. older black background monochrome or today's night/day color theming. Because it feels so objective and programmers are a logical bunch, both sides search for logical backup for what is ultimately personal preference. When you have divisive preferences, one "healing answer" is to provide "all of the above" in as coherent a way as possible. Some might say identifier normalization is already an attempt along these lines, but it is not the only choice.

As a concrete idea related to @AngelEzquerra and @elcritch suggestions and to @dom96's more brief point above and my own Forum comment years ago, I wonder if a viable compromise is:

• default to no identifier normalization but have an import mod {.unstyled.} (similar to import mod {.all.}).

This import macro could instead be a parameterized style converter. E.g.,

• import modA {.style: snakeToCamel.}
• import modB {.style: normalized.}.

Something like this allows library users to declare the style they want without necessarily flattening the namespace and also to work around specific problems explicitly. Defining modules could also have some optional global pragma {.style: normalized.} to declare what they intend next to the program text, not in compiler configs.

Either of these would address the "but it might create bugs in old libs" issue for most but not all use cases. E.g., @deech's p_r_OC would always fail. They probably do not simplify the implementation, but a "style translating import hook" might factor the broader problem constructively. And, yes, it does mean that if modB author changes their style that client imports must change.

Regardless of how you feel about this specific "style translating import" idea or whether any compromise is possible, this topic has arisen often -- not just on disputatious internet forums like HN, but also on the Nim Forum/IRC/etc. That filters for people willing to give Nim a somewhat serious try. You can also probably find many good points/discussions by searching for "insensitivity". Those who are long-time Nimmers are definitely self-selected for either strongly preferring the global ident normalizing choice or are sufficiently not strongly opinionated about it to stick around.

[pietroppeter]

I think style insensitivity should stay.

• @exelotl has explained well some of the small ways where it helps daily life and I think in case it goes away I would miss it more than I can reasonably expect
• I do not find compelling the argument that "it is one of the main reasons that people do not even try Nim". The philosophy of Nim has not been to please specific crowds but trying to do the "right" thing (see picking python indentation for what started as a system programming language). If case insensitivity is still a "right" thing to do, it should stay. If there are arguments for why it is a problem, it can go away.
• As it has been already argue, case insensitivity is not really a reason for Nim not growing fast as we wished. I would mention as first item the lack of tutorials, examples, articles on how one use it with success. Even before the small ecosystem.
• is it still the "right" thing to do? on top of the small quality of life improvements I see the original arguments about it still holds: 1) allowing to use a library written in a different style with a consistent style, in particular when wrapping stuff from another language; 2) allowing is_ok and isOk mean two different things is a bad idea.

one of the arguments in this thread that tries to argue on merits that it is not a good feature (the only one I can find, but I may have missed others) is the one by @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.

It seems to me that this is not due to style insensitivity but on the rules for valid identifiers:

Identifiers in Nim can be any string of letters, digits and underscores, with the following restrictions:

• begins with a letter
• does not end with an underscore _
• two immediate following underscores __ are not allowed:

Indeed I would support a change where the only restriction for a valid identifier becomes:

• begins with a letter or an underscore

(this would not be a breaking change so it is not really necessary to discuss it for nim V2)

As a related note, I particularly appreciate the discussion happening here and I think it is a good thing to having raised this point. It helped me understand better how I feel about this feature (I started as: well, I kind of like it, but I do not really have a strong opinion; I ended with: mmh, no, really I would prefer it stays and maybe let's change something else).

[detlefla]

My feelings on style insensitivity are mixed.

• Being able to use different styles for the same name within the same source file is weird.
• Being encouraged not to use similar names for different objects within the same source file, like isOk and is_ok, is a good thing.
• The possibility to use a different style for other people's interfaces, whether they are implemented in a different programming language (and follow its style) or just follow those people's strange tastes, is also a good thing.
• Magic happening behind the curtain is not a good thing. If names that look different are mapped to the same entity, this may come as a surprise for an unsuspecting user.

Maybe pragmas (or any other form of declaration) could help to avoid nasty surprises and at the same time reap some beneficial effects of style insensitivity.

[kaushalmodi]

I think that getting rid of this feature will lose more users than we gain. Think of the number of packages and libraries this will break in the wild!!

I personally find this feature useful as it allows me to map snake case convention C libraries with my own Nim libraries.

The same dev effort can be put to so much more useful things than make this style change.

[Wh1teDuke]

Against. Would an optional warning when style is inconsistent satisfy those who want to remove the feature?

[ghost]

@Wh1teDuke repeating myself from above, but such a thing --styleCheck:hint already exists. It's really easy to add one more option to it to allow to warn on inconsistency instead of just hinting.

[ee7]

Note that --styleCheck:usages also already exists since Nim 1.6.0. It wasn't mentioned yet, and I suspect that many people are unaware; for example, the below isn't entirely true:

Additionally, --styleCheck enforces camelCase which is not what I want.

From the Nim 1.6.0 changelog (2021-10-19):

• The style checking of the compiler now supports a --styleCheck:usages switch. This switch enforces that every symbol is written as it was declared, not enforcing the official Nim style guide. To be enabled, this has to be combined either with --styleCheck:error or --styleCheck:hint.

To illustrate, consider the below code in a file named foo.nim:

let foo_bar = 1
echo fooBar

Currently, the above compiles successfully (the rules for identifier equality are specified here). Furthermore, when compiling with the default compilation options (just nim c foo.nim), there is no styleCheck hint/warning.

When adding the --styleCheck:hint or --styleCheck:error options, the compiler complains both about the style of the declaration violating NEP-1, and the inconsistency:

$ nim c --styleCheck:hint foo.nim
/tmp/foo.nim(1, 7) Hint: 'foo_bar' should be: 'fooBar' [Name]
/tmp/foo.nim(2, 6) Hint: 'fooBar' should be: 'foo_bar' [let declared in /tmp/foo.nim(1, 7)] [Name]

$ nim c --styleCheck:error foo.nim
/tmp/foo.nim(1, 7) Error: 'foo_bar' should be: 'fooBar'

Adding --styleCheck:usages, it complains only about the inconsistency:

$ nim c --styleCheck:usages --styleCheck:hint foo.nim
/tmp/foo.nim(2, 6) Hint: 'fooBar' should be: 'foo_bar' [let declared in /tmp/foo.nim(1, 7)] [Name]

$ nim c --styleCheck:usages --styleCheck:error foo.nim
/tmp/foo.nim(2, 6) Error: 'fooBar' should be: 'foo_bar' [let declared in /tmp/foo.nim(1, 7)]

To those who are unfamiliar with Nim, note that identifiers are case sensitive for the first character. So the below does not currently compile:

let foo_bar = 1
let fooBar = 1

but this does:

type
  Person = object
    age: int

let person = Person(age: 42)

---

So, echoing @FedericoCeratto, I think we should give serious consideration to the middle way where we make some style-checking behavior the default. Especially if we:

provide a good explanation on the safety and readability benefits

I also liked @pietroppeter's comment, and the idea to consider whether it is sufficient to loosen the rules for a valid identifier.

I think languages should be designed for people who actually use them. It would be a shame if we remove a good feature partly because Nim cannot be discussed on Hacker News without a dominant thread about style insensitivity being bad. We might be able to improve that with an article about the rationale for the design, and more explanation for it in the docs (and maybe at time of compiler hint/error - similar to how we added "DEBUG BUILD, -d:release generates faster code" so that people stop thinking that Nim is slow).

But I would agree that growing Nim should be one of the main priorities. So I guess I'd support removing style insensitivity if that truly was the thing to grow Nim beyond all imagination. But I don't think it is.

And if we did agree that it's a good feature, but nevertheless removed it, don't we have to change the first rule in the Zen of Nim? Perhaps to "copying bad design is not good design, unless everybody else does the bad design, and we cannot persuade people to use the language because of the good design"?

That's a little unfair, since we can argue that some extreme case of "good design" that is too alien for anybody to use is not actually "good design". But still.

[nc-x]

I personally like style insensitivity. And I would prefer if no middle situation is excepted. Either remove style insensitivity or let it remain but just don't make --styleCheck or the nep1 flag the default. The style mentioned there might be something that the core team prefers, but a lot of people do not follow it or do not want to follow it and I don't want to get useless warnings in those cases. Still, if you want to think about making it the default, fix nimpretty first, so that it is easy to get code in the correct style.

[v3ss0n]

Please remove it , it would be hell to find a function and lookingup documentations when different poeple with different styles develop different libs. For example startHttp in one framework , another framework uses start_http , then i won't know which one to find (in documentations and code).

[quantimnot]

@v3ss0n That can possibly be a pain when using common terminal tools, IDE search, and completely custom doc generators. However, the standard doc generation for web docs and nimgrep (-y option) for the terminal support style insensitivity.

[zedshaw]

Hi Nim community, I have a proposal for you to consider. For those who don't know, I wrote Learn Python the Hard Way, and I've also been a huge fan and watcher of Nim. I wanted to do my next course based on Nim, but to be entirely honest, Style Insensitivity (SI) was the only blocker. Everything about the language is fantastic, and there isn't anything necessarily right or wrong with SI, but it's a blocker for new entrants to the language for three reasons:

1. Beginners are frequently confused by ambiguity in things like error messages and syntax, and ironically being loose on style sensitivity makes things more confusing for them. As they progress it's probably a nice feature, but in the start it's confusing to see the same thing being mentioned in multiple ways.
2. For experts it's simply a weird feature they don't really see an advantage to and don't want to like. Disagree with them all you want, but that's just how they (I) feel (felt) about the feature, so trying to force it on them just makes them go to another language that's comfortable.
3. I also feel that SI doesn't fit with the rest of the Nim philosophy of giving the programmer control. One of the things that really attracts me to Nim is that I'm not being dictated to on how I should use it. SI though feels like I'm being forced to use a feature I don't particularly want to, and I suspect other people will feel that removing the feature also is forcing them into something they don't want.

Therefore, I suggest a compromise:

Add a pragma that simply turns style insensitivity off or on.

There you go. No need to remove it, since everyone who already uses Nim really likes that feature. With a pragma, people who come from other languages can simply turn it on and get their familiar strict style back. I can instruct beginners to start with SI off, and then turn it on later when they're more comfortable with the language. Existing code continues to work no problem with new code being able to use it or not. And, in the situation of C libraries with conflicting naming it could help resolve those errors by simply tagging their source as style strict.

Finally, I'll propose a deal:

If the Nim project either adds an SI switch pragma, or completely removes it, then I will create a completely free course for beginners with both written and video content and host it--including the videos--for the project. If there's any time in the future where I can't afford to host it then I'll offer to donate the course to the Nim project if they can find hosting.

Either way, good luck in whatever you choose.

[moigagoo]

I've been thinking about it for some time and I'm voting against removing style insensitivity.

I'm doing frontend work in Nim now with Karax and I love the fact that I don't have to know exactly how to spell onclick. Is it onClick or onclick? Is it onDragStart or onDragstart or ondragstart?

The Nim answer and in my opinion the right answer is, it doesn't matter and it shouldn't matter. Remembering these things is not what a programmer should do. You should be able to focus on the logic and not pleasing the compiler.

I think being able to enforce single style on the project level is enough to address the main issue people have with SI: “you can't grep it.” With switch("styleCheck", "usages") added to config.nims you guarantee that every identifier is greppable.

[PMunch]

I've been writing Nim now for many years, and style insensitivity is one of the features I really miss when I occasionally have to write a different language. I can see that there are some arguments against style insensitivity, the one I agree with the most is the one about wrapping other languages in Nim. This is certainly something which has caused a small amount of headache as I implemented Futhark, but in all honesty it's not that bad. Because it turns out that most people tend to do the sane thing and not have myFunction and my_function or myfunction do different things. They do this because having an identifier which is read the same way by the programmer in their head do different things is not a great design.

I also want to go through the points that @zedshaw brought up:

1. Have you actually tried teaching beginners Nim? I've been teaching beginners myself in other languages and I've noticed errors on more than one occasion where they didn't get the casing of a procedure or type correct. I agree that having multiple ways to do the same thing can be confusing to newcomers, but I think features such as UCFS would be much more confusing than style insensitivity. If anything I think style insensitivity would be helpful as they wouldn't have to be as strict with their typing and can focus on what their programs are actually doing.
2. As an expert I disagree, I really like the feature. It certainly sounded a bit odd when I first heard about it, but now I wonder why not every language out there has this great feature. Experts tend to be a bit stuck in their ways, and Nim challenges a lot of the normal ways of doing things. But as experts we shouldn't be scared of new things, after all that's how our field progresses. We should be the ones who not only dips our toes in but submerges us fully in new things because after all we're the people who can most easily make heads and tails of confusing concepts. And when we surface we can tell the people back on shore what we've found. Of course most experts just wants to carry on with what they know, maybe in fear of not being seen as an expert anymore. But I digress.
3. This I disagree wholeheartedly with. One of my major points of joy around the style insensitivity feature is exactly that it enables me a level of control I don't get in other languages. If you write a library in snake_case but I want to use camelCase then I can simply import your library and use it exactly the way I want to use it. If that's not giving me control I'm not sure what is. Of course I don't have the control to force other programmers to do what I want, but why should I? That just means that they no longer have control. Writing code in Python always left me with a code-base that was a hodge podge of inconsistent styles caused by the libraries I used. Importing a library in C written by someone who just got back from a vacation doing C++ leaves you with much the same. So no, style insensitivity doesn't take away programmer control, it gives us the control we need to write the code we want. As long as what you want isn't myFunction and my_function to do two separate things, but you should probably take a long cold shower and have a think about what you're doing first if that's the case.

Besides, as @moigagoo pointed out, Nim already has a way to force style sensitivity. Currently it's a bit limited, the feature could certainly expand a bit (we just have to make careful so that you can import a library from a different style without the compiler complaining too much).

So at the end of the day, no, I don't agree that we should remove this feature. It's a very nice feature.

EDIT: Oh and by the way @zedshaw, as you can see we already have a switch for it, so I'm looking forward to the course :) Just let me know if you need help with hosting.

[ringabout]

style:usages has already been enabled for stdlib tests => https://github.com/nim-lang/Nim/pull/19715. So with latest devel branch or upcoming 1.6.6 release, it should be fine to enable this switch if you only import stdlib stuffs. The next step should probably be enforcing it for important packages as much as possible (tests only).

[Clonkk]

Style Insensitivity (SI) was the only blocker. Everything about the language is fantastic, and there isn't anything necessarily right or wrong with SI, but it's a blocker for new entrants to the language for three reasons:

It's really sad to see experienced programmer think in such a dogmatic way that they end-up stuck over superficial matter.

The question I want to ask is how many times in a program do you have variables or proc with the same name but different casing ? Do you think having isOk, is_ok and isok be different variable or proc a good practice you'd recommend to a beginner ?

Beginners are frequently confused by ambiguity in things like error messages and syntax, and ironically being loose on style sensitivity makes things more confusing for them. As they progress it's probably a nice feature, but in the start it's confusing to see the same thing being mentioned in multiple ways.

Catering a programming language to beginner's mistake is not good design. Also as @PMunch mentionned, beginners will also make casing error and fail to spot it.

For experts it's simply a weird feature they don't really see an advantage to and don't want to like. Disagree with them all you want, but that's just how they (I) feel (felt) about the feature, so trying to force it on them just makes them go to another language that's comfortable.

It's indeed different from the norm and experts may not be used to it; but dismissing it without trying is a mistake (it does take a while to get used to) and an experts should know better than to be dogmatic in their way of thinking.

I was skeptical at first about it as well, but after working with Nim for a while now, I have to say that I miss it when I come back to other language. From what I can read here, the familiar names in the community also seem to think this way.

Therefore, I suggest a compromise:

Add a pragma that simply turns style insensitivity off or on.

There is already a compile switch that exists as @PMunch mentionned. Since it seems it's not well known here's the relevant part of the compiler documentation

--styleCheck:off|hint|error
produce hints or errors for Nim identifiers that do not adhere to Nim's official style guide https://nim-lang.org/docs/nep1.html
--styleCheck:usages
only enforce consistent spellings of identifiers, do not enforce the style on declarations

Reading all this and the importance this superficial question has, I would suggest to replace "style insensitivity" for "optionnal style insensitivity" .

Finally, I'll propose a deal:

If the Nim project either adds an SI switch pragma, or completely removes it, then I will create a completely free course for beginners with both written and video content and host it--including the videos--for the project. If there's any time in the future where I can't afford to host it then I'll offer to donate the course to the Nim project if they can find hosting.

That's a cool offer, thanks. Looking forward to reading / watching your contribution :)

[ee7]

An idea that wasn't mentioned yet: if we remove style insensitivity, could the compiler produce a hint/warning (or even an error?) ~for each set of identifiers that differ only in style~ when declaring an identifier that differs only in style from one that was already declared?

This would help preserve one (but not all) of the things that people like about style insensitivity: the guarantee that there is no identifier with a similar name (e.g. myFunction, my_function and myfunction).

Also note that there is already a way for a user to turn a hint or warning into an error (since Nim 1.6.0 and Nim 1.4.0 respectively). For example:

{.hintAsError[XDeclaredButNotUsed]:on.}
const bar = 1

$ nim c foo.nim
/tmp/foo.nim(2, 7) Error: 'bar' is declared but not used [XDeclaredButNotUsed]

Similarly:

echo "hi".string

$ nim c --hintAsError:ConvFromXtoItselfNotNeeded foo.nim
/tmp/foo.nim(1, 10) Error: conversion from string to itself is pointless [ConvFromXtoItselfNotNeeded]

[Clonkk]

An idea that wasn't mentioned yet: if we remove style insensitivity, could the compiler produce a hint/warning (or even an error?) for each set of identifiers that differ only in style?

What is the difference between what you're suggesting and --styleCheck:error ?

[ee7]

Sorry, my wording was unclear. I've tried to improve it above.

What is the difference between what you're suggesting and --styleCheck:error ?

Currently, the below does not compile (due to the redefinition):

const isOk = true
const is_ok = true

But if we remove style insensitivity, then it would compile. This would be a new category of thing to "style check" - the idea is to complain about it by default.

And if we remove style insensitivity, the behavior of styleCheck is up for debate (for example, I think --styleCheck:usages would no longer have anything to do). But I have illustrated all the current styleCheck behaviors in https://github.com/nim-lang/RFCs/issues/456#issuecomment-1114777059.

I think I'm still in favor of keeping style insensitivity. But if we did remove it, I'd like at least the ability to make such "declaration of similar identifiers" an error in my own code.