[IshKebab]

> It’s intent is to allow a given codebase to maintain a consistent style (eg camel vs snake) even when making use of upstream libraries that use different styles.

This doesn't make sense. For an entirely new language you can just have the entire ecosystem use the same style, e.g. like Rust does. Or even Python!

[hexo]

It actually makes a lot of sense. I personally don't want to touch .Net langs because of their PascalCase and camelCase coding style which I find very unfortunate arbitrary decision. And well, didn't really want to get into Nim because of camelCase but since I've learned about this feature I'm reconsidering again.

[maleldil]

Do you really dislike camelCase that much to avoid an _entire_ ecosystem because of it?

I prefer snake_case too, but avoiding a language because of a minor convention like that seems weird.

[hexo]

Only language where I can stand it is Haskell. camelCase is relatively ok, but PascalCase for non-types (i.e. function names) is a big no-no :)

[gilrain]

When there are so many excellent languages to choose among, a trivial distinction can almost be a relief.

[stavros]

I'd agree, if you want a consistent style, ship a formatter with your package manager, like Rust does with `cargo fmt`. If it's there by default, it'll quickly be a standard.

[aEverr]

there are many packages and maintainers of such who just dont give a damn about the formatter or the style, some people just *want what they want*

[stavros]

Sure, but there's a standard formatter, they become a small minority.

[aEverr]

and with style insensitivity they become a non-issue?

[stavros]

The compiler might not be sensitive to style, but *I* am.

[atom_arranger]

I guess the best thing would be having a formatter that can switch the style for you locally. I don’t think Nim has this currently, would be neat if they did.