[LLVMdev] Correct use of StringRef and Twine

[Chris Lattner]

On Jul 24, 2011, at 6:31 PM, David Blaikie wrote:
>>> This keeps things simple & seems to be "good enough" to me, but we
>>> could perhaps do better (at the very least, again, if we did do
>>> better, we could go back & remove TwineString & again fix all the
>>> places that fail to compile with whatever new hotness we invent)
>> 
>> This definitely seems like a step forward.  While it is kinda gross, a subclass of StringRef is probably the lowest friction path to do this.
> 
> Come to think of it - is there any use for StringRef other than as
> function arguments?

StringRef is useful for other things, for example the parsing logic in ReadCheckFile in utils/FileCheck.cpp uses it effectively.  It really wants "reference into another string" that is efficient to .substr() etc.

>  If we get Twine to be 'better' for function
> arguments than StringRef, then StringRef goes away - or put another
> way: StringRef could be converted into TwineString (with or without a
> rename) rather than deriving/duplicating the functionality into two
> types.

I think we still want StringRef as a simple "pointer+size tuple".

>>> Hmm - new thought: what would happen if my argument type was simply
>>> TwineString? If I knew my function needed access to the values (like
>>> the Host.cpp example) but didn't have any buffer of its own that it
>>> needed to use, that seems OK.
>> 
>> I'm dubious of this.  This is exposing an implementation detail to clients that they shouldn't have to know, and if passed by value, this could be expensive.
> 
> Yeah, I'm on the fence about this. If we're OK with an extra line
> (declaring the TwineString) for every string (Twine) argument, that
> seems livable.

Yeah, seems better than what we have today at least :)

-Chris