Make chop and chomp return SubString

[TotalVerb]

This is unfortunate:

julia> const str = "x" ^ 100000 * "\n";

julia> @benchmark split(str, '\n')[1]
BenchmarkTools.Trial: 
  samples:          10000
  evals/sample:     8
  time tolerance:   5.00%
  memory tolerance: 1.00%
  memory estimate:  192.00 bytes
  allocs estimate:  4
  minimum time:     2.99 μs (0.00% GC)
  median time:      3.21 μs (0.00% GC)
  mean time:        3.26 μs (0.00% GC)
  maximum time:     8.44 μs (0.00% GC)

julia> @benchmark chomp(str)
BenchmarkTools.Trial: 
  samples:          10000
  evals/sample:     1
  time tolerance:   5.00%
  memory tolerance: 1.00%
  memory estimate:  97.78 kb
  allocs estimate:  3
  minimum time:     9.35 μs (0.00% GC)
  median time:      10.81 μs (0.00% GC)
  mean time:        13.47 μs (10.56% GC)
  maximum time:     790.80 μs (94.19% GC)

I suspect that the same reason that split returns SubString applies to chop and chomp also. The clear benefit of returning a view is performance and allocation avoidance; the disadvantages are that the underlying string cannot be freed, and accessing a SubString is slightly slower. However, in chop and chomp's case, the disadvantage is incredibly slight—an extra byte or so that can't be freed—so I believe it would make sense to follow split here.

Note that Perl, the only other language I know with chop and chomp, has these as in-place operations—which is even faster than creating a SubString, but not appropriate for Julia's conventionally immutable Strings.

On another note, I wonder whether it might be worthwhile to make String into String{T}, so that a string's underlying data can be an array view—which would make SubString substantially faster.

[nalimilan]

I think @StefanKarpinski has a plan regarding SubString and strings sharing the same underlying array.

[stevengj]

LGTM (needs a rebase).

[TotalVerb]

Rebased. On another note, I noticed the doctest:

julia> a = string("March")
"March"
julia> chop(a)
"Marc"

seems to use string("March") for no apparent reason. I think this is a little misleading since it seems to imply copying the string is needed to use chop. I can fix this in a separate PR.

[tkelman]

The return type should be tested for if you don't want it to regress accidentally. The string call is probably a bad find-replace from utf8.

[stevengj]

I would just fix the doctest in this PR, @TotalVerb.

[StefanKarpinski]

LGTM as well.

[TotalVerb]

I made the doctest fix locally. Do I need to rebuild helpdb or something? @stevengj

[stevengj]

You change the docstring in the source, run ./julia doc/genstdlib.jl to re-generate the manual, and then commit the changes.

[TotalVerb]

OK, is this all right? Thanks for the help, @stevengj.

[stevengj]

LGTM.

[kshyatt]

Do the doctests still pass with this change?

[TotalVerb]

The doctests don't pass, but I don't know if that's this change's fault. Failures seem unrelated to me.

[TotalVerb]

It looks to me like most of the failures are due to line numbers being not the same as expected?

https://gist.github.com/TotalVerb/d81e7fff617d315f51ecd019aac4f553

[TotalVerb]

Bump.

[KristofferC]

Not very important but I think that typically we use short circuiting ... && return ... for this. But it was like this before the PR too.

[KristofferC]

This got lgtm from both Stefan and Steven so should be OK to merge?

[kmsquire]

News item?

[kmsquire]

Sorry, that should have been a comment.

[TotalVerb]

Sure, I'll write up a NEWS.