feat: add iotyper linter

[fujiwaraizuho]

Adding iotyper linter.

This linter detects iota usage in const declarations without explicit type specification.
Explicit type annotation improves code clarity and type safety.

Example

This linter flags the following code:

// ❌ Bad: iota without type specification (will be flagged)
const (
    StatusPending = iota
    StatusActive
    StatusClosed
)

// ✅ Good: explicit type specified
const (
    StatusPending int = iota
    StatusActive
    StatusClosed
)

[CLAassistant]

All committers have signed the CLA.

[boring-cyborg]

Hey, thank you for opening your first Pull Request !

[ldez]

In order for a pull request adding a linter to be reviewed, the linter and the PR must follow some requirements.

• The CLA must be signed

Pull Request Description

• It must have a link to the linter repository.
• It must provide a short description of the linter.

Base Requirements

These requirements are not declarative; the team will verify them.

• It must not be a duplicate of another linter or a rule of a linter.
• It must not have false positives/negatives.

Linter

• It must have a valid license:
  • AGPL is not allowed
  • The file must start with LICENSE (capitalized)
  • The file must contain the required information by the license, ex: author, year, etc.
• It must use Go version <= 1.24.0
• The linter repository must have a CI and tests.
• It must use go/analysis.
• It must have a valid semver tag, ex: v1.0.0, v0.1.0 (0.0.x are not valid).
• It must not contain:
  • init()
  • panic()
  • log.Fatal(), os.Exit(), or similar.
• It must not modify the AST.
• It must have tests inside golangci-lint.

The Linter Tests Inside Golangci-lint

• They must have at least one std lib import.
• They must have integration tests without configuration (default).
• They must have integration tests with configuration (if the linter has a configuration).

.golangci.next.reference.yml

• The file .golangci.next.reference.yml must be updated.
• The file .golangci.reference.yml must NOT be edited.
• The linter must be added to the lists of available linters (alphabetical case-insensitive order).
  • enable and disable options
• If the linter has a configuration, the exhaustive configuration of the linter must be added (alphabetical case-insensitive order)
  • The values must be different from the default ones.
  • The default values must be defined in a comment.
  • The option must have a short description.

Other Requirements

• The files (tests and linter) inside golangci-lint must have the same name as the linter.
• The .golangci.yml of golangci-lint itself must not be edited, and the linter must not be added to this file.
• The linters must be sorted in alphabetical order (case-insensitive) in the lintersdb/builder_linter.go and .golangci.next.reference.yml.
• The load mode (WithLoadMode(...)):
  • if the linter uses goanalysis.LoadModeSyntax -> no WithLoadForGoAnalysis() in lintersdb/builder_linter.go
  • if the linter uses goanalysis.LoadModeTypesInfo, it requires WithLoadForGoAnalysis() in lintersdb/builder_linter.go
• The version in WithSince(...) must be the next minor version (v2.X.0) of golangci-lint.
• WithURL() must contain the URL of the repository.

Recommendations

• The file jsonschema/golangci.next.jsonschema.json should be updated.
• The file jsonschema/golangci.jsonschema.json must NOT be edited.
• The linter repository should have a readme and linting.
• The linter should be published as a binary (useful for diagnosing bug origins).
• The linter repository should have a .gitignore (IDE files, binaries, OS files, etc. should not be committed)
• Use main as the default branch name.

Workflow

• A tag should never be recreated.
• The reviews or changes should be addressed as commits (no squash).

---

The golangci-lint team will edit this comment to check the boxes before and during the review.

The code review will start after the completion of those checkboxes (except for the specific items that the team will help to verify).

If the author of the PR is a member of the golangci-lint team, he should not edit this message.

This checklist does not imply that we will accept the linter.

[ldez]

I have several remarks.

iotyper is a bad name because it seems related to io and not iota.

It's better if the repository and module names are the same as the base package. (avoid non-letter characters)

I don't see the point with having an builtin standard type for iota.
First because a iota is an untyped integer, so not exactly a int.
Using int can be a problem on 32-bit arch if the value is higher than math.MaxInt32.

This doesn't feel like a good practice: I can understand the usage of explicit custom type when defining enum, in some cases.
But your analyzer will lead to the usage of builtin type (int, etc.) and IMO this is false-positives.

// ❌ Bad
const (
    StatusPending int = iota
    StatusActive
    StatusClosed
)

// ✅ Good but only if this is useful to have a type.
type Status uint64

const (
	StatusPending Status = iota
	StatusActive
	StatusClosed
)

Based on my previous remarks, as a standalone linter, I think this is not a good idea, but I also think this can be an option (not enabled by default) of iotamixing.

[fujiwaraizuho]

@ldez
Thanks a lot for your feedback.
First, I will update the name of iotyper, as well as the repository and module names.

Sorry for the confusing example — to clarify:
iotyper is not intended to enforce using a standard type (like int) for iota.
Its purpose is to enforce that iota always has an explicit type, not to encourage untyped or standard integer usage.

So the intention is not to allow something like:

const (
    Foo int = iota
)

but rather to ensure that when iota is used for enum-like values,
a custom, explicitly defined type is used, such as:

type Status uint64

const (
    StatusPending Status = iota
    StatusActive
    StatusClosed
)

[ldez]

Its purpose is to enforce that iota always has an explicit type, not to encourage untyped or standard integer usage.

I already understood the objective, but your linter will result into encouraging builtin types usage.
The users will see the reports, add a random type or ignore the reports.
This will be interpreted as the behavior of an analyzer with false-positives.

but rather to ensure that when iota is used for enum-like values

This is not what your linter is doing: it reports all missing explicit types.
And all your examples and your tests are illustrating the problem.

[fujiwaraizuho]

@ldez
Thanks for the clarification — that makes a lot of sense.

You're absolutely right that, as currently designed, the linter ends up encouraging the use of standard types, because users may simply add int (or another arbitrary type) to silence the warning.
That is definitely not the intended behavior, and I agree this would effectively look like false positives from the analyzer.

And yes, you are also correct that the current implementation reports all missing explicit types, not just enum-like usages. The examples and tests indeed reflect this unintended behavior.

Given your feedback, I'm thinking of revising the rule so that it only applies when iota is used in a context where an enum-like custom type is expected — and not enforcing explicit types globally.

Before I move in that direction, I want to confirm:
Would a rule that only enforces explicit types for enum-style constants (with custom types) be more appropriate in your view?

Thanks again for pointing out the issue — it’s been very helpful.

[ldez]

Inside golangci-lint we differentiate 2 types of analyzers:

• the linters (find problems with nearly 0 false positives)
• the detectors (detect potential problems, and so a majority of false positives)

The detectors are not allowed because of the number of false positives.

IMO, your analyzer is currently a detector: it detects missing explicitly typed iota.
But having an explicit typed iota is not a requirement, and doesn't really improve the readability, and can lead to usage of builtin types.
So, this can be interpreted as false-positives.

I think we agree on that.

Maybe, if your analyzer was forcing the usage of dedicated types, so being more opinionated, it could be see as a linter, but even in this case I'm not sure, I need to think about.