[kazinator]

Ah, but does the real name appear together with the Nim name in some line of code that binds them together, which your editor can jump to if you want to know where that Nim name is defined?

If it's just some construct that defines a call to FooBar in the foreign library, with no mention of foo_bar, but elsewhere in the Nim code we call it as foo_bar, I'm afraid I cannot agree with this being a good technical decision in language design.

I wouldn't sign off on such a concealment ruse even if it were someone's macro, not being upstreamed into a language implementation at all.

[beagle3]

That _is_ the nim name. It's just case-and-underscore insensitive so you definitely can if your editor is Nim aware (at the very least emacs, vim and vscode have been aware for a long time; nimgrep is a command line tool similar to grep that is aware of nim's sensitivity rules.

You don't have to agree, you don't have to like it, you don't have to use Nim, and you don't have to think it's a good idea. But any reasonable sampling of real world use shows that it's not a bad technical decision. I don't think it shows it's a great technical decision either; It just shows that it's acceptable and comparable in mental and operational burden to any other decision.

It seems whether it is a little better or a little worse, it will take years of experiment to get any kind of statistical significance.

[kazinator]

> That _is_ the nim name.

Well, a nim name; there is no the nim name.

> you don't have to use Nim,

That would be the lucky situation for now; if we band together and write cogent criticisms, we may be able to keep it that way going forward.