I think that boolmap could be a better name than boolset. There is no notion of Set in Go.

IMHO, this is an "early optimization" linter: there is no problem of using map[]bool, even the Go team uses them inside Go.
It may be an improvement, but always applying this rule is a bad practice, because in most cases, readability is more important than possible optimisations in edge cases with a big map.
I, personally, will never use it.

For now, I don't know if this linter will be accepted; I need to think about it.

Hi @ldez, I appreciate your feedback.



In Golang there isn't a built-in set container type. Sets are just maps but don't care about element values. In Go, map[Tkey]struct{} is often used as a set type. Many Go devs prefer map[T]struct{} for sets because it



- uses zero-size values,



- encodes intent (“presence only”) instead of a tri-state (true/false/absent)
,



- can shave a bit of memory/CPU in large sets




In my opinion the only justified case to use map[T]bool is when we use both true AND false values in it. For example in this case we do want to have false value and we use it as a cache.

	workDone := make(map[string]bool)
	for _, item := range workItems {
		// can be both true and false
		workDone[item] = DoSomeWork()
	}

	for _, item := range workItems {
		if workDone[item] {
			// value successfully processed earlier
		} else {
			// calculation failed but we do not wat to recalculate
		}
	}

However this is quite rare case and my linter will not complain about such use cases.

The suggested linter warns only about usages where map is used as a set with true values only.







My motivation to add this linter is that I found many projects on the internet actually prefer this notation, see my merged PRs to Bbolt, dolt and Xray-core.






At some point I realized that having a linter for this type of issues would make greater impact than just manually fixing them.







As to the naming, boolset actually says what it does: "bool map which is effectively used as a set"

I think the boolset name is fine since it is more or less representing a set. I interpret the name as something like "don't use bool, it's a set".

I agree this is a small optimization in most cases, but I also think a lot of developers aren't aware of ZST (one could say this is as close as we get in Go) and simply avoid this pattern because they're unaware of it.

This is something I use personally even for small collections just to make it clear it's a set and not a map I want to represent, a complement to good variable naming without having to put the type in the variable name. So even though the readme mentions memory and performance, I think this might be just as valid as a code style linter.

I do realize a lot of users wants to roll their own implementation and avoid dependencies, I wonder if encouraging something like deckarep/golang-set to even better represent a set would be a good/better idea.

as an example, here is collections.Set type that typescript team uses specifically to avoid invalid map[T]bool usages
https://github.com/microsoft/typescript-go/blob/1ca5a2d97b0c2b93cfc32137c8922185b4f41df0/internal/collections/set.go#L6

IMHO linter should just highlight the issue and not suggest using specific implementations







My motivation to add this linter is that I found many projects on the internet actually prefer this notation

This is an over-interpretation of your PRs:

1. There are no expressions of preference inside the reviews.
2. Some maintainers, inside those PRs, say the same thing as I about "early optimization".

I have a problem evaluating this linter as a "style" linter because, like prealloc, it will be used as a performance requirement instead of something that should be evaluated on a case-by-case basis.
In most cases, this impacts the readability and doesn't provide any improvement.

I have already closed several PRs on my various projects related to preallocating slices or maps in unnecessary cases or on other types of "early optimizations".

I still need to think about this linter.

I do realize a lot of users wants to roll their own implementation and avoid dependencies, I wonder if encouraging something like deckarep/golang-set to even better represent a set would be a good/better idea.

IMHO linter should just highlight the issue and not suggest using specific implementations

I agree that a linter should not recommend a lib, and this lib specifically should be avoided because of the dependency on the mongo-driver.

This linter is at the borderline between a detector and a linter.

Based on my analysis of several projects, this linter has false negatives (ex: map[string]map[string]bool).
And, once again, in most cases (more than 90%, based on my analysis), the reports can be evaluated as false positives (no huge maps, no concrete performance impact).
This moves the balance to the detector side.

I don't want to reproduce the prealloc situation.

No decision for now.