This suggestion doesn't seem to fit with the scope section of https://go.googlesource.com/lint/+/refs/heads/master/README.md. It would also cause lint warnings in a few places in the standard library, such as matchStringOnly in testing/testing.go or Filter in go/ast/filter.go or HandlerFunc in net/http/server.go. Linter warnings in the standard library aren't the worst thing, but they suggest that there is perfectly reasonable code that doesn't use function parameter names in func types, and we don't want to have linter warnings for perfectly reasonable code.

I suggest that you use your own tool for this, perhaps based on lint, to give warnings for code that violates your preferred style. It doesn't seem like something appropriate for the general purpose tool.

If the rule specifically was that the function was exported the parameters that are function types should have a function type specification and the specification should have default parameters. That probably would bypass the issue you mention about the standard library because you are probably referring to internal functions. If they are internal functions their reuse potential is basically nonexistent anyway.

Two of the examples I cited from the standard library are not internal functions, as you can see from their names.

Since it makes no changes to functionality, those standard library function typed parameters being nicely specified would break no promises and is obviously not a high priority but also is a tiny amount of work, and clears up the linter problem (which is why to make it in the linter).

It's just good manners, I think, but not obvious until you write a lot of handling libraries. Once you have copied the signature, added arbitrary names to the parameters so you can use the function a few times you start to notice that it would be nice if you didn't have to think of the names every time. By making it not flag non-exported function type function parameters also it isn't getting in the way when you only mean to write one or two different handlers for it and maybe think in future you need an easy option to add more, but aren't thinking that you want users of the library to do it.

I have a pretty strong opinion about exporting and the use of internal, personally. I default to not exporting symbols unless they need to reach outside of their scope, but if it helps reusability and reduces obstructions to re-engineering/re-architecting when things are exposed. Some things don't have to be, so they are fine. But it's damned stupid to completely hide them in internal IMO. I've found more than a few times I needed something inside an internal folder. Only way to reuse that is to copy and paste and do a lot of refactoring. This reduces maintainability. I don't think it serves any purpose whatsoever, except some kind of vanity about one's ability to predict the future.

I agree that naming the parameters would not break compatibility. That wasn't my point. My point is that as a general rule lint should not emit any warnings for well written idiomatic Go code. We think that the Go code in the standard library is well written and idiomatic. So the fact that the proposed warning would trigger on code in the standard library is a mark against it.

/cc @matloob

Doesn't the linter have 'recommendations' and not just 'this is (probably) bad code' warnings?

Yes. But it remains the case that we don't expect the linter to fire on ordinary code.

Also, again, see the Scope section of https://go.googlesource.com/lint/+/refs/heads/master/README.md. That describes the kind of changes we expect to implement in x/lint.

I'm sure you read those documents well, maybe even contributed a lot to them, but I see nothing in it that mentions function types much less function types as parameters. It's not 'out of scope' it's 'not been mentioned'. If that's where the contribution would be made, how does one go about submitting an amendment of these?

See the comments at the top of https://golang.org/wiki/CodeReviewComments.

https://github.com/golang/go/wiki/CodeReviewComments#named-result-parameters

That seems to be quite in agreement with my proposal, just doesn't directly address the use of functions as parameters to functions. It even mentions the fact right at the end that closures create extra conditions under which parameters in function signatures should be named, that could easily be expanded.

Thanks, I'll see if there is any interest in such an amendment as the link suggests (to make a discussion post in the wiki)

The behavior of lint is pretty much frozen at this point. I'd suggest making a different tool that provides these parameters. We've got a bunch of packages such as golang.org/x/tools/go/analysis that makes making these tools pretty easy.

It's not a static analysis feature it's a lint feature. It doesn't affect compilation in the slightest, nor performance, whether you put names in there or not makes no difference to the binary that comes out, at all.

The analysis framework provides tools for writing tools that suggest diagnostics like the one you're suggesting adding here, and also provides a way to suggest code replacements to users too. Diagnostics and analyses don't need to affect compilation or performance to be produced by or written with the analysis framework.

#37495 was declined, so closing this one as well.