Should Unused Parameters be Ignored or Not?

[Wajinn]

There has been lots of debates about this, in many languages. It is often argued that an unused parameter is like unused variables, however, I'm of the opinion that's not the case. A variable is usually more about a deliberate action by the programmer to complete specific tasks. Function arguments, however, can often reflect the intention to do a wide variety of tasks, have more flexibility, and can also be part of libraries (modules) used by a great number of users.

Unused parameters can become an insidious issue for numerous reasons: 1) Library creators or those creating modules for future use, arguably can not predict nor anticipate all possible outcomes in advance. This would be even more of an issue for newbies and casuals, who we would or should not expect to rewrite libraries. 2) The intention can be for the function to produce different results, based on parameters used. 3) The flow state of the programmer can be affected, where they are forced to adopt a programming style they don't like or are not used to. 4) Interoperability and translation problems between languages, where unused parameters are handled differently.

Different languages, have different strategies to mitigate or circumvent the annoyance of unused parameters. They can allow for optional parameters, unnamed parameters, are not strongly typed, use method overloading (same method name with different parameters), etc... Interestingly, vlang has none of those ways to mitigate or circumvent in that way, possibly creating an issue.

There are some "vlang ways" to handle it, that probably should be shown in the documentation, but there is still the matter of backwards compatibility and updating. The issue of previous functions needing to be rewritten to adhere to newly implemented "policies" or "preferences". And rewriting functions, to say use structs or interfaces as the parameter, can be time intensive or require significantly different thinking in the design of the module.

[JalonSolov]

Well, V does already have a way to deal with unused function parameters, the same way Go does it... use _ for the parameter name.

fn foo(_ int) int {
        return 5
}

foo(3)

Perfectly valid code, compiles clean.

The only real question is whether or not V should complain about unused variables. Currently, it does. It didn't in the past, but now for this slightly different code:

fn foo(x int) int {
        return 5
}

foo(3)

You'll see something like this:

x.v:1:8: notice: unused parameter: `x`
    1 | fn foo(x int) int {
      |        ^
    2 |     return 5
    3 | }

Now... why would you even want an unused parameter... perhaps as a placeholder? You're still thinking about what parameters the function will need, but maybe you've just created a stub for now?

I don't know what the "best" way to do this is. I've seen probably every variation amongst different languages... some languages just ignore it altogether. Some give you a warning about unused parameters. Others will give an error.

I've pretty much come to the opinion that the "best" way is whatever the language you're using does - that's what's best for that language.

In other words, there is no "best way". Just do what the language needs you to do in order to write your code.

[Wajinn]

Well, V does already have a way to deal with unused function parameters, the same way Go does it... use _ for the parameter name.

True, we can use _, but that's seems more for when a person is creating their own modules or writing code for themselves. Not sure if that's an effective strategy for published and endorsed modules, that's for general usage by newbies and casuals. But who knows, maybe _ will become more of a thing in libraries, though it seems like structs or interfaces are the "unstated" preference to be something like optional parameters.

We do have -n and -w flags to turn off notices and warnings, but perhaps it should be considered to make this even more convenient and at the module level, or at least temporarily (during the 5.x version run). This then gives more time for library writers to catch up or feel less pressure.

Perhaps use an underscore in front of the module's name, that disables display of -n or specifically allows usage of unused parameters. Instead of import ui, it could be import _ui. The other side of the argument, is to push for rapid adoption of different thinking, but how fast will libraries get updated?

In other words, there is no "best way". Just do what the language needs you to do in order to write your code.

I partially agree, that there is no "best way", as depends on the language. However, there can be the expectation of a certain level of consistency (even if beta) or there to be an overall consensus as to what is the "best way" by its community.

[Wajinn]

Perhaps it would be good to show vlang style "option parameter" like alternatives, in context to the unused parameter issue:

1. Use of _ underscore.

fn foo(_ int) int { return 5 }

2. Use of a struct. Can omit or give no parameters.

@[params] 
struct Arg {
	x string 
	y string
}

fn faz(arg Arg) string {
    return "${arg.x} and ${arg.y}"
}

3. Use of trailing option type. Parameter v can be omitted.

fn far(x bool, v ?int) (bool, int) {
	y := v or {0} // unwrap
	return x, y
}

[squidink7]

Something I haven't seen many people mention is one of the most frequent times I find myself leaving parameters unused is for anonymous functions that need to match a certain signature, such as event handlers in GUI apps.

gui.button(
    text: 'click me'
    on_click: fn (b Button, w Window, e Event) {
        // b, w, and e remain unused
        println('pressed!')
    }
)

This does work with _, and as long as unused parameters in general remain possible in some way without warnings then patterns such as this will still work.