<br>Here's a smaller version/start of my twine changes - perhaps it'll be easier to bite off to review.<br><br>The description from my initial attempt:<br><br>Here's some more <span class="il">Twine</span>-ification of APIs. I realize this seems like a<br>

somewhat random assortment - I haven't, for example, fully changed<br>
some types to <span class="il">Twine</span> (so there might be some functions in a type that<br>
take <span class="il">Twine</span>, others that take StringRef still), but it does seem to be<br>
stable & I didn't want to just keep piling on more code.<br>
<br>
API changes:<br>
* <span class="il">Twine</span><br>
  * appendTo(std::string&)<br>
    Works like "toVector" but on std::strings. (I'd like to rename<br>
toVector to appendTo to make it clear it's appending, not overwriting<br>
- I added test cases to expose this existing deliberate design because<br>
when I 'fixed' it by clearing the vector in toVector I broke a bunch<br>
of stuff that was relying on it being appending)<br>
  * assignTo(std::string&)<br>
    clear() + appendTo<br>
* StringRef<br>
  * StringRef(const char (&)[N])<br>
    an array constructor so it doesn't have to use strlen for string<br>
literals. For some reason this doesn't work in GCC (try making the<br>
StringRef(const char*) ctor explicit & GCC starts complaining about<br>
how it can't convert the const char* in 'return "foo";' into a<br>
StringRef). This is a little tricky - it doesn't include the trailing<br>
null character if one is present. This is to maintain compatibility<br>
with the existing implicit conversion from string arrays via the<br>
(const char*) ctor.<br>
  * assignTo(std::string&)<br>
    the same idea as <span class="il">Twine</span>::appendTo(std::string&). This is more<br>
efficient than using str = strRef; because it doesn't produce an extra<br>
temporary buffer to return through. ctor initialization (std::string<br>
str = strRef;) is still efficient due to RVO.<br>
  * booleanTest()/SafeBool<T><br>
    I've made StringRef boolean testable so it can be used as a drop<br>
in replacement when null tests are required<br>
* TwineString - a type that makes retrieving/manipulating a <span class="il">Twine</span><br>
value a little simpler. Yes, it's a little dodgy that it derives from<br>
StringRef but it's 'good enough' to make Twines the default string<br>
arguments - any time you see a StringRef or std::string argument there<br>
should be a specific explanation.<br>
<br>
One current problem I have is that SmallString<T> is convertible to<br>
StringRef and StringRef to <span class="il">Twine</span>, but that seems to be insufficient to<br>
implicitly convert from SmallString<T> to <span class="il">Twine</span> - so I've added a few<br>
explicit <span class="il">Twine</span>(smallstr) calls around. If there's a better way to<br>
approach this (ultimately we could add a SmallString option to <span class="il">Twine</span>,<br>
but it'd be sort of nice not to have to do that either) I'm all ears.<br>
<br>
Aside: <span class="il">Twine</span>::<div id=":j3">toNullTerminatedStringRef scares me. A lot. It relies on<br>
UB to leave the null character beyond the end of the allocated buffer.<br>
Could we fix this to return a StringRef that doesn't include the null<br>
character (though I'm not sure this bit should matter, really - code<br>
asking for the null terminated StringRef is probably doing it to pass<br>
to a C API that's not going to care about the StringRef's concept of<br>
length), but leave the character itself in the buffer? (& I was<br>
thinking we could check if the <span class="il">Twine</span> was a non-empty StringRef<br>
already, test the last character for null, then return a StringRef<br>
over that rather than using a new buffer - though this wouldn't work<br>
for my current StringRef(const char(&)[N]) ctor, since the length<br>
won't include the null character).</div><br>