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

spec: should len(a) (and cap(a)) be constant for a of type parameter type constrained by same-size arrays? #50226

Closed
griesemer opened this issue Dec 16, 2021 · 8 comments
Assignees
Labels
NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone

Comments

@griesemer
Copy link
Contributor

Reminder issue to consider this case. See also #42029 for background.

This can wait for 1.19 as going from a non-constant to a constant result for len and cap is a backward-compatible change (I think, since the type doesn't change, it's always int).

@griesemer griesemer added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Dec 16, 2021
@griesemer griesemer added this to the Go1.18 milestone Dec 16, 2021
@griesemer griesemer self-assigned this Dec 16, 2021
@griesemer
Copy link
Contributor Author

Note that the spec currently says:

The expressions len(s) and cap(s) are constants if the type of s is an array or pointer to an array and the expression s does not contain channel receives or (non-constant) function calls; in this case s is not evaluated.

If it said

The expressions len(s) and cap(s) are constants if s is an array or pointer to an array and the expression s does not contain channel receives or (non-constant) function calls; in this case s is not evaluated.

and we look at array (and pointer to array) as structural types, then we may need to make the result constant in some cases. The effect on real-life programs is negligible, this is mostly a spec precision issue.

In the implementation it would mean changing a call to under to structuralType.

cc: @ianlancetaylor

@go101
Copy link

go101 commented Feb 26, 2022

Moving this to Go1.19 means it will be always as such. It is a problem same as aConstString[i:j].

@go101
Copy link

go101 commented Feb 26, 2022

BTW, it looks it is disallowed to pass addresses of array type parameter values to len:

package main


func f[T [2]int]() {
	var x T
	const _ = len(&x) // invalid argument: &x (value of type *T) for len
	var _ = len(&x)   // invalid argument: &x (value of type *T) for len
}

func main() {
	type T [2]int
	var x T
	const _ = len(&x) // okay
}

@griesemer griesemer modified the milestones: Go1.19, Go1.20 Apr 19, 2022
@griesemer griesemer modified the milestones: Go1.20, Go1.21 Nov 15, 2022
@griesemer griesemer modified the milestones: Go1.21, Go1.22 Jun 6, 2023
@griesemer
Copy link
Contributor Author

Too late for 1.21 if anything needs to be done here.

@griesemer
Copy link
Contributor Author

Moving to 1.23. We're not going to change this for 1.22.

@griesemer griesemer modified the milestones: Go1.22, Go1.23 Nov 1, 2023
@griesemer
Copy link
Contributor Author

griesemer commented Feb 8, 2024

Looking at this some more, this just seems to be a bug. Sending out a fix for review/discussion.

@griesemer
Copy link
Contributor Author

This is a (if minor) language change and thus needs to go through the proposal process. Closing this issue in favor of #65592.

@griesemer
Copy link
Contributor Author

griesemer commented Feb 8, 2024

See also https://go.dev/cl/562349.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Development

No branches or pull requests

2 participants