Implement Base.one for StringView

[mnemnion]

I have a lot of S where S<:AbstractString code which uses one(S) for the empty string to compare against. I didn't realize until I went to add this that typemin also works, but hey, that makes the implementation that much easier, and StringViews gives me a zero-copy drop-in replacement for a string buffer with this addition.

[stevengj]

Looks good to me, can you add a test?

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.08%. Comparing base (7c7f0b6) to head (83796dc).
Report is 24 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #24      +/-   ##
==========================================
+ Coverage   75.05%   77.08%   +2.02%     
==========================================
  Files           6        6              
  Lines         417      467      +50     
==========================================
+ Hits          313      360      +47     
- Misses        104      107       +3     

Flag	Coverage Δ
unittests	77.08% <100.00%> (+2.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mnemnion]

Done. I admittedly have been making these edits through the GitHub interface, after trying them in the REPL. It looks like tests run under CI? I'm willing to clone and run locally if necessary.

[mnemnion]

Good catch, a careful look at the documentation also turned up oneunit, which doesn't fall back on one, so I defined it also.

[mnemnion]

This commit got rid of the custom oneunit, and one/oneunit/typemin all work on StringView{Base.CodeUnits{UInt8,String}} due to an added special case.

It adds a convert to the StringView's underlying data type from the StringView, which I consider legitimate. I didn't add a test for this because the code pathway is exercised by the typemin tests, but adding one would be pretty easy, if the maintainers consider the convert legitimate in the first place.

[mnemnion]

Just chiming in to say that I intend to squash all of this into one commit whenever you think it's in a good state to merge. I ended up checking in some spurious data among other things.

Speaking of which, would you accept a separate PR which adds Manifest.toml to a .gitignore? Can't hurt.

I'm not in a rush here, to be clear. I ended up switching two calls to use typemin instead of one, which works fine for my application, and means I use a better lower bound on the dependency.

[stevengj]

I don't like including a Manifest.toml file in the repo, but .gitignore is fine.

[mnemnion]

I don't like including a Manifest.toml file in the repo, but .gitignore is fine.

Right, I removed it once I realized it came from me. The .gitignore is simply to prevent that happening in future.

[mnemnion]

Would you say this is ready to go? I'd like to squash it, so the spurious check-ins don't end up in the tree. I've held off because that should really be done once.

[stevengj]

Thanks, I squashed and merged.