This is an archive of the discontinued LLVM Phabricator instance.

Add StringRef::keep_front() and StringRef::keep_back()
ClosedPublic

Authored by zturner on Aug 27 2016, 7:42 PM.

Details

Summary

I've needed these methods time and time again, but always resort to using some incantation of slice(), substr(), or drop_front() / drop_back() with a length calculation.

While these methods are extremely simple, they can make certain operations very elegant, especially when you want to slice up a string in various ways and you want to chain the operations together.

Diff Detail

Repository
rL LLVM

Event Timeline

zturner updated this revision to Diff 69499.Aug 27 2016, 7:42 PM
zturner retitled this revision from to Add StringRef::keep_front() and StringRef::keep_back().
zturner updated this object.
zturner added a subscriber: llvm-commits.
zturner updated this revision to Diff 69500.Aug 27 2016, 7:54 PM

Added the same functions for ArrayRef and MutableArrayRef

Sounds like a useful API. The term I've heard of in other programing languages is "take", I think take_front and take_back might be a little nicer.

Sounds like a useful API. The term I've heard of in other programing languages is "take", I think take_front and take_back might be a little nicer.

take_front sounds ok, but take_back sounds awkward to me. I almost want to say "take what back?" If the convention was drop and rdrop, then take and rtake would sound good, but I'm not crazy about take_front and take_back. I could probably be convinced though if the majority prefers it.

grandinj added inline comments.
include/llvm/ADT/ArrayRef.h
340 ↗(On Diff #69500)

this explanation can't be right

348 ↗(On Diff #69500)

or this one

zturner updated this revision to Diff 69513.Aug 28 2016, 8:41 AM

Fixed incorrect function descriptions.

chfast added a subscriber: chfast.Aug 28 2016, 2:26 PM

Sounds like a useful API. The term I've heard of in other programing languages is "take", I think take_front and take_back might be a little nicer.

take_front sounds ok, but take_back sounds awkward to me. I almost want to say "take what back?" If the convention was drop and rdrop, then take and rtake would sound good, but I'm not crazy about take_front and take_back. I could probably be convinced though if the majority prefers it.

So maybe take_first and take_last?

Adding a few more people for comments.

amccarth edited edge metadata.Aug 29 2016, 1:22 PM

I'm torn on the naming debate. I think take_back is awkward, and using first and last instead of front and back would make the new names inconsistent with drop_front and drop_back (and with STL container naming). I also see that point that keep is less precise.

Everything else LGTM.

rnk edited edge metadata.Aug 30 2016, 7:33 AM

I don't feel strongly, but I'll toss in a vote for take_front / take_back. "Keep" sounds like it's modifying the string in place.

This revision was automatically updated to reflect the committed changes.