FYI, there are already helpers in slices for this, overlaps and startIdx.
Maybe they are not exactly what is needed for this proposal, but they do exist. ('startIdxis O(n), but only because it wasn't necessary to make it faster.) The comment instartIdx` is particularly relevant - what if the pointer points in the slice, but is not exactly at the start of any element?

The comment instartIdx` is particularly relevant - what if the pointer points in the slice, but is not exactly at the start of any element?

With my proposed implementation, it returns -1, since there's a p == &s[i] check before returning the index. Having the optimized variant match the naive implementation seems the least surprising and also answers how each edge case should be handled.

Another edge cases exists with slices of zero-length element types. Again, the optimized version matches the naive implementation in behavior.

As a concrete example of pre-condition error checking, for flate.AppendCompress (#54078), I wanted to have it reports an error if src is a subslice of dst. This is tempting to do and will often be okay since the output is usually smaller than the input. However, that is not guaranteed as it is possible that compression produces a larger output than the input. When this occurs, the output is corrupted and it can be extremely difficult to figure out why. It is better to report an error up front.

I would rather see:

func IndexPointer[S ~[]E, E any](s S, p *E) (int, bool)

I don't like -1, it's not obvious from the signature how it fails or what I should check for.

The existing Index and IndexFunc functions already set the precedence that -1 means "not found". I'm not sure if we should change that here.

Ah nvm, well forget what I said. thx

A use of this is to check whether some slice is a subslice of another slice, by checking:
len(subslice) > 0 && slices.IndexPointer(s, &subslice[0]) >= 0

Technically subslice might extend past the end of s, so this isn't a test of whether some slice is a subslice of another slice, it's a test of a more complicated condition. You could fix that by adding
&& slices.IndexPointer(s, &subslice[len(subslice)-1]) >= 0

What if we instead use Overlapping[E any](s1, s2 []E) bool? That could return true if s1 and s2 overlap--share any elements. The order of the arguments doesn't matter. You only get a bool result--is that enough for your purposes?

For the use cases that I'm wrestling with, Overlapping would work. I like that it resolves the 1st, 2nd, and 4th issues that ContainsSubslice would have.

That said, I think IndexPointer is still a useful function as it serves as a lower-level primitive with well-defined semantics.
The fact that Overlapping could be implemented in terms of IndexPointer shows its flexibility:

func Overlapping[S ~[]E, E any](s1, s2 S) bool {
	return len(s1) > 0 && len(s2) > 0 && (
		IndexPointer(s1, &s2[0]) >= 0 ||
		IndexPointer(s2, &s1[0]) >= 0 ||
		IndexPointer(s1, &s2[len(s2)-1]) >= 0 ||
		IndexPointer(s2, &s1[len(s1)-1]) >= 0)
}

We could provide both IndexPointer and Overlapping, but I'll still take Overlapping over nothing.

The real win would be to teach the compiler that seeing if slices.Overlapping(s1, s2) { return } means it can assume non-aliasing beyond that point. That would be huge for optimization.