Allow use of `_xxx` with `unused-parameter` rule

[Gusted]

Is your feature request related to a problem? Please describe. We're enabling the unused-parameter rule on our repo to detect if there are possible bugs. A lot of parameters can be changed to _, but in certain cases it will make the code more unreadable

Describe the solution you'd like Add a option(or by default) that certain use-case are allowed, this can be limited to just the _ prefix or a generic regex option. Using the _ prefix is common in JS to still have the variable name but show that the variable is unused.

Describe alternatives you've considered Adding the //revive:disable... comment, but that's better to avoided for each function that needs this.

Additional context None

[chavacava]

Hi @Gusted thanks for filling the issue.

Using the _ prefix is common in JS to still have the variable name but show that the variable is unused.

It is common in JS but not in GO, to the point that golint (thus revive) will warn you with a: don't use underscores in Go names

[Gusted]

I see, fair point.

Thank you for your response.

[silverwind]

Is it out of question to have a rule configuration option for this? It could allow the user to define a regex pattern. The default pattern could be ^_$ and users would be free to define ^_ for example.

[chavacava]

Is it out of question to have a rule configuration option for this?

Not at all. My intention with the previous comment was to highlight that prefixing identifiers with _ is not idiomatic in GO

It could allow the user to define a regex pattern

Yes, it is something that could be studied

[twmb]

Prefixing with _ is common for fields in structs when you want to define a struct but not have it exported. This is commonly used for forcing users of the struct to specify all fields, and to specifically pad the struct. This can be seen within the Go stdlib itself:

$ rg '^\s+_[a-zA-Z0-9]+\s+[a-zA-Z0-9]'
syscall/syscall_freebsd.go
144:		_p0          unsafe.Pointer

runtime/defs_plan9_amd64.go
31:	_type uint64

runtime/stack.go
1373:	_ptrdata int32 // ptrdata, or -ptrdata is GC prog is used

runtime/defs_linux_ppc64.go
184:	_pad0       int32

runtime/defs1_netbsd_amd64.go
97:	_signo  int32
98:	_code   int32
99:	_errno  int32
100:	_pad    int32
...

(I have to disable structcheck and unused for this in golangci-lint)

[chavacava]

@silverwind thanks for joining to the discussion

could you provide more details about the use of _ in structs?

Prefixing with _ is common for fields in structs when you want to define a struct but not have it exported

Do you mean _ disables the struct or the field to be exported? What is the difference between

type something struct {
  signo int32
}

and

type something struct {
  _signo int32
}

This is commonly used for forcing users of the struct to specify all fields,

I know that adding a blank field is a hack to force you to use field names when instantiating a struct (https://go.dev/play/p/hJeg6a0D_x9) But prefixing fields with _ does not have any effect (https://go.dev/play/p/xPuOwJ8CY9m) What I'm missing?

[...] and to specifically pad the struct.

What do you mean by pad the struct and how _ helps in that?

[twmb]

I know that adding a blank field is a hack to force you to use field names when instantiating a struct TIL that a field in a struct can literally be named _! I've always used _somename. My concern is largely moot now.

[silverwind]

Can't really comment much on golang practices, but I'm using the ^_ pattern in JavaScript via eslint which allows to define a regex pattern and I thought it would be great to have this flexibilty too in golang.

Eslint has distinct pattern configuration for various types of variables (primarly arguments and regular variables), maybe this is something to consider to split into multiple options too.

[comdiv]

I've not see allwedRegex argumnet in unused-parameter implementation, so i think it's not too hard add it there with ^_$ by default.

[comdiv]

Think same is for unused-receiver

[comdiv]

Provided MR for this feature