Maybe we should limit constructor functions to the ones start with "New".

Is that what you are proposing ? Then it should be a proposal, rather than a bug.

It is more a small improvement than a formal proposal.

Re-titled appropriately.

@griesemer , @rsc

NewFoo is just a convention. I see no reason for it to be enforced by such a widely used tool considering how much existing documentation will become "missing" the constructors in the place where they used to be for many years.

Yes, NewFoo is ok to be listed in the Foo type zone, but Get and Post shouldn't be listed there.
For many times, I feel some package-level functions are missing for they are moved from the places where they used to be for many years.

That's clear, but you've missed the point of my objection: fixing false positives comes at the cost of new false negatives that exist for a long time, for example here.

Also, wrt #27812 (comment), why shouldn't http.Get be listed as a constructor of *http.Response if that's exactly what the function constructs?

I don't know, it is my intuition that http.Get is not a constructor of *http.Response.
I think it just happens that http.Get returns a *http.Response.

What about Create and Generate (concrete examples from code I work with) that very much act as constructors? And a plethora of other examples I could pull out of a hat? You're trying to fix one inconsistency by eliminating a whole class of useful behaviour.

I think this is overly restrictive. There's plenty of proper factory functions that don't start with New. Personally, I use NewX for functions that create a new X that is a pointer, and sometimes MakeX for a new X that is not a pointer. @dominikh mentioned a few other patterns as well.

The original go/doc heuristic has worked mostly well. The more recent fine-tuning (exclude functions that return more than one type from the list of factory methods) probably overshot a bit into the other direction. We should correct that one, instead. For instance, a final error result should not be considered as an additional type in the decision making. If there's types in a result that are not declared in the current package, we may want to eliminate those functions as well. There's some fine-tuning we can do that should get as 99% there w/o the need to restrict names.

I'm leaning against this proposal.

how about only view the functions with a Camel-Case style name and the last segment in the Camel-Case name is the same as the base type of a type as the constructors of the type?

See the Create, Generate, Must and New functions in https://godoc.org/github.com/BurntSushi/xgbutil/xwindow – none of which have any suffix, to avoid unnecessary stutter.

OK, so it looks it hard to make a perfect solution for both sides.
I feel the introduction of the concept of "constructor" in godoc is some unreasonable.
It may be better to put a "seen returned by" list in each type zone.

Closed.