On Oct 16, 2016 6:03 PM, "Liam Breck" <networkimp...@gmail.com> wrote: > > > > On Sun, Oct 16, 2016 at 5:32 PM, Ian Lance Taylor <i...@golang.org> wrote: >> >> On Sun, Oct 16, 2016 at 5:25 PM, Liam <networkimp...@gmail.com> wrote: >> > >> > On Sunday, October 16, 2016 at 5:13:36 PM UTC-7, Ian Lance Taylor wrote: >> >> >> >> On Sun, Oct 16, 2016 at 3:34 PM, Liam <networ...@gmail.com> wrote: >> >> > >> >> > On Sunday, October 16, 2016 at 2:56:42 PM UTC-7, Ian Lance Taylor wrote: >> >> > >> >> >> To argue that this should go into the standard library, look at some >> >> >> corpus of Go code and find out how often it occurs. If it occurs >> >> >> fairly often, you've got a good case. >> >> > >> >> > >> >> > Fairly often; i.e. as often as Replace or Trim*? In my experience it >> >> > passes >> >> > that test. >> >> >> >> This is something that can actually be measured. >> > >> > >> > By doing grep 'append.*append' ? And '\[:.*len\(.*\).*\+[0-9]+.*\]' ? >> > Neither of these will be accurate. >> > >> > Part of my point is that Insert operations are semantically obscured. >> >> Understood. But my guess is that insertion operations are fairly >> rare--much less common than Replace or Trim. People obviously append >> to slices all the time, but I suspect that they tend to write their >> slice operations to not require inserting a single element in the >> middle of the slice, because insertion is by definition O(N) rather >> than O(1). I could certainly be wrong, but that guess leads me to >> suspect that adding a function for something that can easily be >> written in a single expression is overkill. Since I am only guessing, >> and since it seems to me that you are also guessing, I think we should >> measure rather than guess. > > > You characterize optimization as a widespread habit. Most code isn't optimized, as it doesn't need to be. Most coders follow the first advice found, which in my case was Insert() on [1]. If you wish the most optimal solution to be widespread, stdlib would be a good vehicle :-) > > I would attempt to provide data confirming my guess, but I can't see how to do that without spending a lot of time hunting for semantically invisible operations. Since there are two authoritative suggestions for this op, it's a reasonable guess that it's widely done. > > BTW, we are having this discussion because fmt does not support thousands grouping, which also seems like a common need. > > [1] https://blog.golang.org/slices
As an alternative to bytes.Insert/Delete how about bytes.Replace(s []byte, pos int, len uint, new []byte) A zero len is insert, and empty new is delete. -- 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 golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
