search for: consume_integer

...rayRef etc to use the exact same API is a good idea long term, but there's a lot of ugly messy details that need to be dealt with. There's thousands of uses of take_front / drop_front, etc that have to be converted. Then there's some methods that aren't in string_view at all, like consume_integer(), consume_front(), etc that would have to be raised up to global functions in StringExtras. All of this can certainly be done, but it's going to be a *ton* of churn and hours spent to get it all STL-ified. > > Do you consider this a blocker for doing such a split? Would it make sense...

...is a good >> idea long term, but there's a lot of ugly messy details that need to be >> dealt with. There's thousands of uses of take_front / drop_front, etc that >> have to be converted. Then there's some methods that aren't in string_view >> at all, like consume_integer(), consume_front(), etc that would have to be >> raised up to global functions in StringExtras. All of this can certainly >> be done, but it's going to be a *ton* of churn and hours spent to get it >> all STL-ified. >> >> Do you consider this a blocker for doing s...

Yes, that proposal makes sense to me: the split would be between things that *are* known to be subsumed into later versions of C++, and therefore are a compatibility library. What do you think about this as an implementation approach: - Rewrite StringRef (et al) to use the exact same APIs as std::string_view. Keep the StringRef name for now. - When cmake detects that C++’17 mode is supported,

...long term, but there's a lot of ugly messy details that need to be >>>> dealt with. There's thousands of uses of take_front / drop_front, etc that >>>> have to be converted. Then there's some methods that aren't in string_view >>>> at all, like consume_integer(), consume_front(), etc that would have to be >>>> raised up to global functions in StringExtras. All of this can certainly >>>> be done, but it's going to be a *ton* of churn and hours spent to get it >>>> all STL-ified. >>>> >>>> Do...

...9;s a lot of ugly messy details that need to >>>>>> be dealt with. There's thousands of uses of take_front / drop_front, etc >>>>>> that have to be converted. Then there's some methods that aren't in >>>>>> string_view at all, like consume_integer(), consume_front(), etc that would >>>>>> have to be raised up to global functions in StringExtras. All of this can >>>>>> certainly be done, but it's going to be a *ton* of churn and hours spent to >>>>>> get it all STL-ified. >>>...