-

[skosovsky]

Proposal

I would like to propose adding blankassign as a built-in golangci-lint linter.

Repository: https://github.com/skosovsky/blankassign
License: MIT
Current tag: v0.1.0
Analyzer type: go/analysis.Analyzer
Linter name: blankassign
Configuration: linters.settings.blankassign.ignore
golangci-lint v2 support: module plugin support already exists

Motivation

blankassign is intended to catch a small but increasingly common cleanup failure mode: values are explicitly assigned to _ only to silence the compiler instead of being handled, removed, or wired into the real logic.

This pattern is easy to introduce during iterative development, especially when code is generated, refactored, or modified by coding agents. An agent may resolve an “unused variable” compiler error by adding _ = value, or leave a temporary stub behind while making a larger change. The code then compiles, but the underlying issue is hidden.

These assignments are hard to find in review because they look syntactically harmless and are often surrounded by otherwise valid changes. In practice, they usually mean one of three things:

• a value was computed but never used;
• a refactor was left incomplete;
• a temporary workaround escaped into committed code.

blankassign makes this intent explicit by reporting only direct single blank assignments such as _ = ctx, _ = result, or _ = compute(). It intentionally avoids idiomatic Go uses of the blank identifier, such as _, ok :=, _, err :=, range, blank imports, and interface assertions.

What it reports

_ = ctx
_ = result
_ = compute()
_ = "pkg"
_ = 42

Example diagnostics:

blankassign: meaningless assignment to _: ctx is not used
blankassign: meaningless assignment to _: expression result is not used

What it does not report

_, ok := m[key]
_, err := fn()
for _, v := range xs {
    println(v)
}
var _ io.Reader = (*T)(nil)
import _ "net/http/pprof"

Why existing linters do not fully cover this

This is adjacent to existing linters, but the policy is different:

• errcheck handles unchecked errors;
• dogsled handles too many blank identifiers in assignments;
• ineffassign and wastedassign handle ineffective assignments;
• unused handles unused declarations.

blankassign focuses only on explicit single _ = value assignments that are commonly used as silencing stubs.

False-positive policy

The rule is intentionally narrow:

• only ast.AssignStmt;
• only token.ASSIGN;
• only len(Lhs) == 1;
• only Lhs[0] == "_".

The optional ignore setting suppresses diagnostics only when the RHS is a simple identifier with a matching name.

Open compliance notes

I am aware of the new-linter checklist and would clean up any repository-level requirements before opening a PR if maintainers are interested. Two known points:

• the current module uses go 1.24.0; I can release a v0.1.1 tag with go 1.22.0 before the PR if required;
• the repository includes a golangci-lint v2 module plugin adapter, which uses init() for plugin registration. If the checklist requirement “must not contain init()” applies repository-wide rather than only to the analyzer package imported by golangci-lint, I can split or remove that adapter before submitting the PR.

Would you be open to accepting blankassign as a built-in golangci-lint linter if I prepare a PR with integration tests and configuration support?

[ldez]

The usage of the discussion template is not optional.

[bombsimon]

You didn't use the new linter proposal template. It contains a lot of valuable information for us to consider new linters so please open a new discussion with the proper template.

Oh, I'm a 🐢