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

builtin: the prototype of the make function should be more consistent with new instead of len #22362

Closed
go101 opened this issue Oct 20, 2017 · 7 comments

Comments

@go101
Copy link

@go101 go101 commented Oct 20, 2017

The prototypes of the three functions are

    func len(v Type) int
    func make(t Type, size ...IntegerType) Type
    func new(Type) *Type

Although these prototypes are only for documentation purpose, the first argument of make is more like a value instead of a type.

An alternative suggestion is to define a fake ContainerType type and modify the prototype of len as func len(v ContainerType) int

@ianlancetaylor ianlancetaylor added this to the Go1.10 milestone Oct 20, 2017
@robpike
Copy link
Contributor

@robpike robpike commented Oct 20, 2017

The words immediately after the prototype for make says Type must be one of slice, map, or chan. Nothing needs to change. The word Type is in turn a stand-in. Yes, it is defined to be any type but the words for make immediately refine its use there.

It would be unwise to introduce the word Container for this, which is not part of the Go documentation. It's a word used by a different kind of language.

I also don't understand what you mean by the doc for make being inconsistent with len and new. It seems consistent to me. I also disagree that the first argument of make is a value. It is not, it is a type.

@griesemer
Copy link
Contributor

@griesemer griesemer commented Oct 20, 2017

The first argument of make is a type, not a value. There is no bug here, and this is not a proper proposal either. Closing.

@griesemer griesemer closed this Oct 20, 2017
@go101
Copy link
Author

@go101 go101 commented Oct 20, 2017

@robpike

I also don't understand what you mean by the doc for make being inconsistent with len and new.

The first arguments of len and make are both Type.
They give people the first impression that they are the same kind of thing.
However one represents a value, the other represents a type.

@go101
Copy link
Author

@go101 go101 commented Oct 20, 2017

My original proposal is to remove the t from the prototype of make to make it consistent with new. Otherwise, I think the prototype should be func make(t Type, size ...IntegerType) t instead of func make(t Type, size ...IntegerType) Type.

@go101
Copy link
Author

@go101 go101 commented Oct 20, 2017

In fact, I have a third suggestion:

    func make(T type, size ...IntegerType) T
    func new(T type) *T

Here the type indicates the argument is a type instead of a value.

I admit that this is not a big problem.
Just try to make it perfect from the academic view. :)

@griesemer
Copy link
Contributor

@griesemer griesemer commented Oct 20, 2017

@go101 Removing t from the signature of make would be syntactically incorrect: Either all parameters have a name or none of them does.

The Type stands for a type, any type. Conceivably, there's a type representing types. It doesn't exist in Go, but this package is just for illustration and serves as a reminder when looking up these functions via godoc. The spec has the final word.

I really don't see much to do here.

@go101
Copy link
Author

@go101 go101 commented Oct 20, 2017

Yes, it is not a big problem.
These prototypes are just some bizarre.
The two Type in the make prototype even represent two different kinds of things,

However, I do understand the situation, by lacking general generic support in Go, it is really hard to make these prototypes academic perfect. ;)

@golang golang locked and limited conversation to collaborators Oct 20, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants