search for: charkind

...s problems. This is the reason that the integer versions of the twine ctor are marked 'explicit'. I'm ok with the Twine class changes in this patch if the ctor is marked 'explicit'. You should also probably add a ctor for signed/unsigned char as well (which reuse the existing CharKind enum). I'll respond to Triple specific issues in response to your previous email. Thanks for pushing this forward David! -Chris

...than it was before. But if the argument is that std::string's interface was poorly designed/unsafe & we can do better/safer, I'm OK with making the ctor explicit as you've suggested. > You should also probably add a ctor for signed/unsigned char as well (which reuse the existing CharKind enum). Hmm - would it be safe to cast those signed/unsigned chars to straight char? (is it guaranteed that the signed & unsigned values with the same representation map to the same glyph?) As a side note on Twine's design: Is there a particular reason it uses void*s rather than unions? an...

> [diff attached] Updated diff with test fix. (since this broke a test (printing chars as numerical values, rather than characters) it's possible this change is a bad idea & it could break the product code itself. Though strangely I wasn't able to do character concatenation without my change, so I have a sneaking suspicion that while the test passed, it didn't actually expose

> And for arguments, generally always use Twine as the default, it allows construction of complex things, and is still efficient when passed the equiv of a StringRef (with the toStringRef method).  The only annoying thing about it is that the API to do this requires a temporary SmallVector to scribble in, which makes it more difficult to use. > > It seems that there should be a good way

...the ctor > explicit as you've suggested. Yes, exactly. I'm just saying that I think the additional clarity of: "foo" + Twine('x') is worth the inconvenience. >> You should also probably add a ctor for signed/unsigned char as well (which reuse the existing CharKind enum). > > Hmm - would it be safe to cast those signed/unsigned chars to straight > char? (is it guaranteed that the signed & unsigned values with the > same representation map to the same glyph?) Yes. I consider 'signed vs unsigned char vs char' to be a blight on the C t...