Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add empty slice declaration check #441

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

@demoManito
Copy link
Author

@quasilyte PTAL

@quasilyte
Copy link
Owner

I think the issue is that nil slice and empty slice are different things and some APIs may require one or another.
CC @cristaloleg

@demoManito
Copy link
Author

I think the issue is that nil slice and empty slice are different things and some APIs may require one or another. CC @cristaloleg

Yes, but I need to detect some empty slices that are not necessary and if not, nolint skips

@demoManito
Copy link
Author

golang/go/wiki/CodeReviewComments#declaring-empty-slices

golang wiki

In most cases, empty slices, simply stating that a nil slice is sufficient

@cristaloleg
Copy link
Collaborator

Yes, but I need to detect some empty slices that are not necessary and if not, nolint skips

Sounds like a too opinionated. I understand you intention but this is not 1:1 replacement.

However, make([]T, 0, 0) doesn't make sense and can be []T{}.

@demoManito
Copy link
Author

demoManito commented Apr 13, 2023

Yes, but I need to detect some empty slices that are not necessary and if not, nolint skips

Sounds like a too opinionated. I understand you intention but this is not 1:1 replacement.

However, make([]T, 0, 0) doesn't make sense and can be []T{}.

etcd-io/etcd#14479

Just like in this PR, most empty slices are meaningless, either defined as var a []T, or need to be assigned cap.

I think these situations need to be reported when needed.

@cristaloleg

@demoManito
Copy link
Author

image
image
image

@cristaloleg
Copy link
Collaborator

most empty slices are meaningless

I agree but blindly replacing it sounds wrong to me, see https://go.dev/play/p/tVN7c2t8kMc

To clarify again: I'm not saying "this a wrong", I'm saying "this check is not for everyone".

Consider to use gocritic (1) or golangci-lint (2) where you can specify this rule

  1. https://github.com/go-critic/go-critic/blob/master/.golangci.yml#L45
  2. https://golangci-lint.run/usage/linters/#gocritic (ruleguard. rules)

@demoManito
Copy link
Author

hello @cristaloleg , go-critic/go-critic#1337 Do you mean to add it here?

@cristaloleg
Copy link
Collaborator

Nah, I meant to add it as a personal ruleguard rule.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants