Why Go allow function with unused arguments?

194 views
Skip to first unread message

Kamil Ziemian

unread,
Jan 30, 2022, 3:01:42 PM1/30/22
to golang-nuts
Hello,

This is a question from ignorant in the meters of compilers and mediocre Go users at best, so it may be stupid.

I really like that in Go unused variable or import is compiler time error. As such I wonder why function like
> func funTest(x int) int {
>         return 3
> }
is allowed? I would guess that it is possible to check if function argument is used in function body or not, so it seem plausible to forbid it.

Again, it maybe a stupid question from ignorant person. I have a lot things to learn about Go, but I'm stuck in learning about Unicode and UFT-8, so I guess it will be a long time before I can go back to learning proper Go. I read FAQ and I didn't remember answer to this question from it. This is my excuse for asking this question.

Best regards,
Kamil Ziemian

Dan Kortschak

unread,
Jan 30, 2022, 3:09:46 PM1/30/22
to golan...@googlegroups.com
It is necessary for methods to sometimes have parameters that are not
used in order for the type to satisfy an interface. Similarly, if
function values are being passed around the signatures will need to
match even if the parameters are not being used.

It is possible to use the blank identifier in these cases to signal
that a parameter is not being used and that can be linted for.

See https://github.com/golang/go/issues/39118 for discussion on a
proposal relating to this.


Robert Engels

unread,
Jan 30, 2022, 4:21:11 PM1/30/22
to Dan Kortschak, golan...@googlegroups.com
To the ops point, wouldn’t it be better to cause an error for unused parameters unless they use the blank identifier?

> On Jan 30, 2022, at 2:09 PM, 'Dan Kortschak' via golang-nuts <golan...@googlegroups.com> wrote:
> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/78c6d5db02f0f35230b60b8324189eb367cee209.camel%40kortschak.io.

Sean Liao

unread,
Jan 30, 2022, 4:47:46 PM1/30/22
to golang-nuts
By enforcing blanks, you'd lose the chance to name them something useful to tell the reader why they're ignored.
eg:
    // why are the last 2 args ignored??
    handleX = func(foo, bar, _, _ string) string { return foo + bar }

Dan Kortschak

unread,
Jan 30, 2022, 9:35:42 PM1/30/22
to golan...@googlegroups.com
On Sun, 2022-01-30 at 13:47 -0800, Sean Liao wrote:
> By enforcing blanks, you'd lose the chance to name them something
> useful to tell the reader why they're ignored.
> eg:
> // why are the last 2 args ignored??
> handleX = func(foo, bar, _, _ string) string { return foo + bar }
>

Probably more significantly at this stage, it's a breaking change to
the language.


Kamil Ziemian

unread,
Jan 31, 2022, 6:40:08 AM1/31/22
to golang-nuts
Thank you kortschak for explanation. It was clear to me why abstraction by interface, require us to allow need unused parameter for methods, it didn't come to my mind that you need to pass the function with proper signature and some of this function may not need to use all parameters from signature. When it will be uncomfortable, it probably occur more times that we want.

I strongly wish that blank identifier will be the norm, but I'm pessimistic about arriving of Go 2. Probably everyone know that Go 2 is not like releases in other languages, when you know that it will be done, unless some big disaster happens along the way. To quote few of the biggest gophers "We may never release Go 2". Backward compatibility is a big asset of Go 1, so I'm pessimistic about Go 2 that need to introduce 3 or 4 breaking changes. Again I quote some big gopher about this 3 or 4 breaking changes.

Best regards,
Kamil

Kamil Ziemian

unread,
Jan 31, 2022, 6:44:37 AM1/31/22
to golang-nuts
> By enforcing blanks, you'd lose the chance to name them something useful to tell the reader why they're ignored.

For me this is quite straightforward: they are omitted because, they aren't needed. True question to me is: why other functions need them? But, this wouldn't be answered by looking at this correct function. For my money, answers lies in place to which you send function with given signature, it decides what and why passed function signature is. I maybe wrong about that.

Best regards,
Kamil
Reply all
Reply to author
Forward
0 new messages