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

Open
griesemer opened this issue Dec 16, 2021 · 1 comment
Assignees
Milestone

Comments

@griesemer
Copy link
Contributor

@griesemer griesemer commented Dec 16, 2021

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 this to the Go1.18 milestone Dec 16, 2021
@griesemer griesemer self-assigned this Dec 16, 2021
@griesemer
Copy link
Contributor Author

@griesemer griesemer commented Dec 16, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant