Hi folks, opinionated piece of potentially X-Y problem following:
Since 0.19, collision between parameters and declarations is not allowed anymore, allowing better machine understanding of our code from the machine and helps at reducing output size. It’s a noticeable change in the day to day coding because, well, things can collide often.
I’ve mostly seen in the wild appending an underscore_. Though, I recently found myself appending an underscore_ to most function parameter names in a personal project, so as an experiment I decided to put it on every single parameter as it saves me some brain power while deciding if it needs one or not. I like that code guideline, but I find it far from ideal mostly because it messes with my autocomplete and also because I find it visually hard to spot mistakes.
As the title states, I’m fairly convinced that a suitable option would be allowing name parameters to start with an _underscore (it’s currently forbidden by the compiler), as it would narrow autocompletion list from the start. It would also be possible to treat those names differently in the syntax highlighting, for those who choose it as a coding style to make it visually spot on.
What do you think? What’s is your favourite way of getting around that limitation? As you may have found a better solution.
In at least one other language (emacs lisp), the convention is that parameters prefixed with an underscore are ignored by the function. That is, the compiler won’t generate warnings about unused parameters for underscore-prefixed names, whereas for ordinary names it does. Elm has a limited version of this in the sense that you can use _ as a parameter name to indicate an unused binding, whose value cannot be referred to in the function, as an enforced feature of the language. (But there are no compiler warnings about named bindings that go unused, AFAIK).
Other languages (e.g. Python) use a convention that underscore-prefixed names (as members of a class for instance) are “internal” and should not be accessed by third-party code. But this is just an orthographic convention with no language support. (Because of elm’s design, privateness of names is not really an issue that arises for us.)
Based on other programming languages, there are several things that underscore-prefixed names could mean (including “nothing special”). I think it would be strange (to me personally, not to generalize to anyone else) to read code where underscores meant “function parameters”. That sounds like an informal and conventional version of something like Perl’s sigils, which I don’t like (and have never fully understood, again this is a very personal opinion).
I do agree that there are issues with the ergonomics of function parameters that shadow names in the module scope (e.g.) – but I don’t think there’s a clear answer yet.
I didn’t meant to force function parameters to start with an underscore, just allowing it from the parser. Code guidelines, even enforced from tools such as elm-format, can convey meaning as you stated. I think teams can benefit from tiny guidelines with big profit. I’m merely just asking for one more option.