Carrot Games

I've just noticed an interesting usage pattern that has emerged for me over time wrt named arguments

I generally really like named arguments, so to me whether they belong or not in a language is not up for discussion. I couldn't care less about the issues frequently brought up, like "names become part of the public API" (so what? you're breaking your public API all the time anyway with named arguments or not) and my favourite non-argument: "I have python-induced trauma from libraries that abused named arguments" (you're not special we're all traumatized by python, your trauma is not language design).

Anyway, one place where named arguments shine is when functions take primitive parameters! It's not mandatory to set the name of the argument (well, depends on the language), but when a function takes a bunch of booleans, I find it almost always pays off in terms of readability to specify the names those parameters.

Maybe this is why people love those inlay hints so much? To me they're just distrtacting because having them *everywhere* means they become part of the background noise whereas placing them with intent where I think it adds value sounds like a way to get nicer and more readable code.

This is the bit of code that inspired this:
It's obvious to me, and thus noisy, to know that the first two parameters are the "ui" and the game's "difficulty", which presumably the objectives hud will care about. Those are also well-typed things that would be hard to mess up, so I can skip the name and it's nice and succint.

For the third argument, though, it makes all the difference because it makes me go from being confused: "Why the heck does the objectives panel want to know about the pause menu??" to understanding a bit more about the system: "Ah, the objectives panel is only interactable when the pause menu is shown!".

That is a great snippet of code to talk about named arguments and the inlay hints you mentioned!

I think inlay hints, for one side, can be really useful if the language doesn't support named arguments. Some very nice behaviour about these is that, if you pass a variable into a function parameter, and the variable name has the same name as the parameter, the hint hides itself.

Taking your code snippet as an example, imagine that your function definition was defined as this:
In the "ui" case, the hint would be hidden, since the variable is named exactly as the parameter.

In the "difficulty" case, I guess it depends on how the LSP is implemented or something for the editor, but personally trying out rust-analyzer in neovim, I get the hint hidden in the second case too! Because, it recognizes that the attribute of a structure has the same name as the function parameter, and so it hides the hint!

But yeah, as you said, I also think it's preferable to have more control about these, instead of depending on these hints. Also, with hints it gets trickier to navigate within the code, because you can miscalculate how many words or characters you need to move if there is a hint in between.

Sugui wrote:but personally trying out rust-analyzer in neovim, I get the hint hidden in the second case too!

Ohh! I knew about the simple case (hiding when using a variable with the exact same name) but I didn't know rust analyzer had more advanced heuristics about this!

Nice