I'd like makeString to be smarter: - If I give it an int it should call String::number. - If I give it my own type it should use ADL to find makeString next to my type, and call that. Making string from strings is cool, but making strings from anything is much cooler. I experimented with this in bug #163919 and it works great: the WebAssembly parser passes templated types into a NO_INLINE fail() function, and that function makes a string from whatever it receives. Some neat things: - It's shorter than string builder which is great because I'm not in the business of making strings, I'm in the business of parsing. Making strings is the drudgery i go through when parsing fails. - NO_INLINE is great because it means I only put effort towards making a string if things go bad. I don't coerce things eagerly / early, and the register allocator is super lazy at trying to call this NO_INLINE function (especially since the call is dominated by a UNLIKELY branch). That means that my code is tuned for parsing, but if things go bad it'll create a beautiful error message. Here's how I propose approaching this: 1. makeString becomes smarter, learns about ADL, and basic conversions are added to it (basic types, and common WTF types which are sensible to makeString). 2. Individual call sites are upgraded in their own patch. No giant change, just small cleanups. WDYT?
(In reply to comment #0) > - It's shorter than string builder which is great because I'm not in the > business of making strings, I'm in the business of parsing. Making strings > is the drudgery i go through when parsing fails. StringBuilder is for when there is no pre-defined "shape" to the string and we want to dynamically add pieces to it. I agree that it would be nice to have a more powerful makeString that can handle integers, for example, without allocating an integer string; the trick would be making sure the semantics of it are clear. > - NO_INLINE is great because it means I only put effort towards making a > string if things go bad. I don't coerce things eagerly / early, and the > register allocator is super lazy at trying to call this NO_INLINE function > (especially since the call is dominated by a UNLIKELY branch). That means > that my code is tuned for parsing, but if things go bad it'll create a > beautiful error message. What you describe here seems like a property of a particular makeString call site rather than a property that makeString itself should always have. Since we are allocating memory it seems clear we don’t need to be too aggressive about inlining.
(In reply to JF Bastien from comment #0) > - If I give it an int it should call String::number. We did this. > - If I give it my own type it should use ADL to find makeString next to my > type, and call that. We sort-of did this, with StringAdapter. Also, all the things that work in makeString work in StringBuilder::append too.