Sure.
@zdjones @rasky @brtzsnr

Need to watch out for blen==MinInt. Then the index succeeds but the slice fails.

@randall77 While not immediately useful, I think it's worth noting that this would no longer be a concern if we adopted #19623 or #31500.

I think the titles suggestion is not safe for when n==MaxInt as n+1 would overflow.

It looks Go 1.12 does BCE for this case.

Some finding:

package main

type T = uint64

func f(s []int, n T) {
	_ = s[n]
	_ = s[:n+1] // BCEed when T is int/uint/int64/uint64 for Go SDK 1.12, but not for tip.
	// I think T=unsignedIntergerType should be ok here.
}

func g(s []int, n T) {
	_ = s[n-1]
	_ = s[:n] // BCEed when T is int/uint/int64/uint64 for Go SDK 1.12, but not for tip.
	// I think T=unsignedIntergerType should be ok here.
}

func main() {}

[edit]: If Go specification can specify (, or gc can limit) that the lengths of arrays/slices/strings may not exceed MaxInt-1 (which is practical), then the second lines of the above two functions can be safely BCEed for int and int64.

@ugorji It seems the bounds check in your example is removed, at least as of 1.12.6. Do you have an example where the bounds check is not removed?

Otherwise this can be closed, fixed somewhere <= 1.12.6

@zdjones did you check the behaviour is correct when n==MaxIntT?

It is impossible for a program to successfully allocate a slice with lengh n == MaxIntT for T is int/uint/int64/uint64, even if the element type is byte. For other signed interger types, if n==MaxIntT, then n+1 is negative, so the bound check can't be removed for sure. For unsigned integer types, n+1 is zero, so the bound check can be removed for sure.

In short, bound check can be removed for int, int64 and any unsigned integer types.

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

This still needs more thought, don't close it yet.

I've started checking the current behaviour near MaxInt and ended up down quite the rabbit-hole (exploring how big of a slice the compiler and runtime will allow, compared with what the spec allows for)

Note that you can make slices of 0-sized items. That will let you test near maxint without using huge amounts of memory.

package main

type T struct{}

func main() {
	s := make([]T, 1<<63-1)
	println(len(s))
}

With @randall77's comment, the conclusion in my last comment is wrong (for int and int64).

It looks the slice expression in the following code has already BCEed at least since Go 1.12.

		_ = b[blen-1] // bounds check: Found IsInBounds (expected)
		use(b[:blen]) // BCEed

So maybe it also should for OP's code:

		b[blen-1] = '"' // bounds check: Found IsInBounds (expected)
		use(b[:blen]) // bounds check: Found IsSliceInBounds (unexpected as above is sufficient)

Rethought it for a while, even if blen is MinInt, the bound check for the slice expression could be also eliminated, for blen-1 is MaxInt, so the expression b[blen-1] will always cause a panic. If it doesn't panic, then the slice expression is absolutely safe.

And it looks this problem only happens for package-level slices or indexes:

package main

var blen int = 1
var b []byte = make([]byte, 1)
var b2 []byte

func fff(b []byte, blen int) {
	type _ int
	b[blen-1] = '"' //  Found IsInBounds
	b2 = b[:blen]
}

func ggg() {
	type _ int
	b[blen-1] = '"' // Found IsInBounds
	b2 = b[:blen] //  Found IsSliceInBounds
}

func ggg2(b []byte) {
	type _ int
	b[blen-1] = '"' // Found IsInBounds
	b2 = b[:blen] //  Found IsSliceInBounds
}

func ggg3(blen int) {
	type _ int
	b[blen-1] = '"' // Found IsInBounds
	b2 = b[:blen] //  Found IsSliceInBounds
}

func main() {
	b[blen-1] = '"' // Found IsInBounds
	b2 = b[:blen] // Found IsSliceInBounds
	
	ggg()
	ggg2(b)
	ggg3(blen)
	
	fff(b, blen)
}

@go101, the compiler assumes global variables can be reassigned at any time. The two reads of b might be completely different slices.

@randall77, then it looks this issue could be closed now, as this problem doesn't happen to local slices.

BTW, more evidences to prove global variables are not BCE friendly.

package main

var blen int = 1
var b []byte = make([]byte, 1)
var b2 []byte
var x byte

func ggg1() {
	_ = b[blen-1] // Found IsInBounds
	b2 = b[:blen]
}

func ggg2() {
	_ = b[blen-1] // Found IsInBounds
	b2 = b[:blen]
	b[blen-1] = '"' // Found IsInBounds
}

func ggg3() {
	_ = b[blen-1] // Found IsInBounds
	b[blen-1] = '"'
	b2 = b[:blen] //  Found IsSliceInBounds
}

func ggg1b() {
	x = b[blen-1] // Found IsInBounds
	b2 = b[:blen] // Found IsSliceInBounds
}

func ggg2b() {
	x = b[blen-1]   // Found IsInBounds
	b2 = b[:blen]   // Found IsSliceInBounds
	b[blen-1] = '"' // Found IsInBounds
}

func ggg3b() {
	x = b[blen-1]   // Found IsInBounds
	b[blen-1] = '"' // Found IsInBounds
	b2 = b[:blen]   //  Found IsSliceInBounds
}

func main() {
	ggg1()
	ggg2()
	ggg3()
}

It looks there is still a little unreasonable in BCE decision making:

package main

var s = make([]int, 100)

func f() (r int) {
	for i := range s {
		r += s[i] // bound check eliminated
	}
	return r
}

func g() {
	for i := range s {
		s[i] = i // need bound check
	}
}

func main() {
}

I filed another issue: #47736