On Tuesday, February 21, 2017 at 1:30:24 AM UTC+8, Ian Lance Taylor wrote: > > On Mon, Feb 20, 2017 at 9:12 AM, T L <[email protected] <javascript:>> > wrote: > > > > I know gc assures this, but I don't know if it is compiler specified or > a > > spec rule. > > I can't think of any way that a Go program that does not unsafe could > detect whether a string slice uses the same memory as the string being > sliced. Also, I can easily imagine that in some cases it would be > desirable to make a copy, as when writing s[i:i+1] when len(s) > 4096 > and there are no other references to s. So I don't think this should > be written down in the spec. I think Go programs should trust that > the implementation will make the right choice, which will of course be > to normally not copy the string. > > Ian >
My intention is to make sure s[a:b] will always share the underlying bytes with s, otherwise strings.Index(s[fromIndex:], sep) would be inefficient if s[fromIndex:] doesn't share the underlying bytes with s. I know gc can assure this. My concern is whether or not other compilers can assure this too if the spec doesn't cover this. And I think if the spec doesn't cover this, a new strings.IndexFrom function should be added to the standard lib. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
