I agree, but the problem is that you don't ever want to do this whether those are three different variables (or is that two?) or whether all are alternative forms of the same case/underscore insensitive name. Nim is going out it's way to make the syntax you have about legal (will all of these equivalent), which strikes me as a bad move.

The best case for usability is that this "feature" never used, which makes it an odd design choice. The worst case is that the feature is used frequently, there is no clear language norm, visually scanning for variables is harder, search and replace requires dedicated tools, and subtle bugs abound. Far better (in my personal opinion) to make identifiers case sensitive and enforce consistency with style guidelines and code "prettifiers".

The current Nim approach is being called cs:partial (case sensitive partial) and makes the first letter case sensitive but all others insensitive. This like an awkward compromise, and needlessly complicated. The best proposal I've seen suggests making "_x" equivalant to "X" (underscore is an alias for "next letter is capital"). But I don't see it as better than case insensitive plus strong code conventions.

I think it would be a lot more palettable if Nim enforced one of those coding conventions per module, while letting users of that module reference it any way they liked. e.g. my team could exclusively use camelCase and the compiler enforced that in our modules, while the same code could be handed off to some other team that exclusively uses snake_case.

In practice, resolving symbols is not really harder. Once you understand the symbols rules, your mind is very good at finding the match. Plus the real solution is proper IDE support with "goto definition". IMO, the benefits of semi-case-insensitivity (allow programmers to write how they want) outweight the issues it causes.

It still means you can't reliably grep code for an identifier. Strikes me as a really stupid wart in an otherwise great language.

go format is a much better solution to the same problem.

You can with NimGrep: http://nim-lang.org/nimgrep.html

If a language's lexical structure is so tortured that I need a special tool to grep it, I'm going to skip it and go back to the sanity of C++.

Ridiculous.

We use "special tools" for every other language (Visual Studios, Eclipse, etc).. Calling a language feature, which give programmers style freedom, a "tortured lexical structure" is not an objective argument. Especially since we have a tool (nimgrep) which addresses the issue and takes < minute to learn. Once Nim has better IDE support, no one will be grepping in the first place.

I don't need special tools to just _search_ a C++ or Java program.

Sure, I can use nimgrep, but I can't use _my_ grep, _my_ freetext indexer, _my_ editing constructs, and so on. I'm not going to make my environment, which works fine for almost all programming languages, bend over backwards to support your special snowflake of a language.

I'd rather just use something else.

> to just _search_ a C++

Please, be serious.

> but I can't use _my_ grep, _my_ freetext indexer, _my_ editing constructs

Oh, but you can! These are _your_ tools, you can easily extend them by either scripting or modifying source, no problems there. Really, how much of a problem is adding a switch for underscore insensitivity to your program? Because I assume case insensitivity you had already coded.

Oh, unless by "_your_ grep" you meant a tool that someone else wrote and you're using without any real understanding of how it works and without required skill or knowledge to modify it. Right, this can happen, you're a busy man, have many obligations and no time at all to fiddle with grep. I understand.

But that also makes you completely outside of a target group of early adopters of new programming languages. So maybe stop commenting on them?

How about distinguishing between public, private and protected properties? How about being able to quickly identify classes versus instances? How about explicit is better than implicit?