cmd/compile: extra bounds check when accessing string using index from range over its runes

[fice-t]

Go version

go version go1.26-devel_e1a12c7 Mon Nov 17 13:45:54 2025 -0800 linux/amd64

Output of go env in your module/workspace:

Workspace is `go.godbolt.org` on `x86-64 gc (tip)` as above.

What did you do?

Compile this simple example from the standard library:

func hasUpperCase(s string) bool {
	for i := range s {
		if 'A' <= s[i] && s[i] <= 'Z' {
			return true
		}
	}
	return false
}

(As an aside: is there a reason why the above doesn't iterate over the bytes of s instead?)

What did you see happen?

Extra bounds check on s[i], even though per-spec i should still always be 0 <= i < len(s) even on invalid UTF-8.

What did you expect to see?

No extra bounds checks.

This also appears elsewhere in the standard library, such as strings.ToValidUTF8, fmt.truncateString, and time.tzsetNum.

[gabyhelp]

Related Issues

• cmd/compile: lack of BCE in for loops without inline increment #75184 (closed)
• cmd/compile: strings.HasSuffix has extra bounds check (len(s)-delta) #76304 (closed)
• cmd/compile: Extra bounds checking when using addition in condition/index #76270
• cmd/compile: No BCE for str[len(str):] #53409 (closed)
• cmd/compile: missing BCE in range expression #54753 (closed)
• cmd/compile: performance issue with ranging over string #13162 (closed)
• cmd/compile: unnecessary bounds check when indexing slice from range #71439 (closed)
• cmd/compile: unnecessary bounds checking using result of intrinsic function #58334 (closed)
• cmd/compile: teach prove.go that {strings|bytes}.Index* return value in the range [-1 .. len(s)) #25862

Related Code Changes

• cmd/compile: don't produce a past-the-end pointer in range loops

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[randall77]

(As an aside: is there a reason why the above doesn't iterate over the bytes of s instead?)

That's just the way the language was designed. Kind of odd, I agree, but we can't change the semantics now.
Use for i, b := range []byte(s) to get byte indexes and values. And no bounds checks.

It is a little bit odd to access the string using s[i] when iterating over runes. Better to do for _, r := range s and use r instead of s[i]. The examples you cite are doing s[i:] or s[:i], which seem less odd.

It is probably doable to get rid of the bounds check for s[i] (and s[i:] and s[:i]), just doesn't seem particularly high priority.

[fice-t]

That's just the way the language was designed. Kind of odd, I agree, but we can't change the semantics now.

Oh, I wasn't referring to that. I was just wondering why hasUpperCase chooses to range over runes instead of bytes as it's only checking an ASCII range. I was wondering if I was missing something.

It is probably doable to get rid of the bounds check for s[i] (and s[i:] and s[:i]), just doesn't seem particularly high priority.

Understandable. When typing this up, I was hoping that the logic for BCE here could be tied in with the []byte(s) case, but that was probably wishful thinking.