Core type names and keywords for string types

[zygoloid]

Summary of issue:

What should the names we use in Core for string view and string buffer types be? What should the corresponding keywords be, if any? Should we also have a type for a nul-terminated string view, and if so, with what name?

Details:

We discussed this during the 2025-07 Carbon summit. The leading option seemed to be:

• String view type: Core.Str with keyword alias str
• String buffer type: Core.StrBuf with keyword alias str_buf

The toolchain has reached the point where it needs an answer for its implementation. We should establish a leads position on this question.

Any other information that you want to share?

For a nul-terminated string view type, Core.CStr or Core.ZStr might be good choices.

Another possible option would be to spell the Core. names out in full: Core.String and Core.StringBuffer / Core.StringBuf.

A related question is what name we use for our contiguous dynamically-sized array type, for which the leading contender currently is Core.Buf with keyword alias buf.

[chandlerc]

My two cents lean towards:

• Core.Str
• Core.StrBuf
• Core.CStr
• Core.Buf

My leaning between CStr vs. ZStr is minimal and happy to switch if there is evidence that Z is a better sigil.

[danakj]

+1 on CStr, FWIW.

Can the StrBuf keyword be strbuf?

[chandlerc]

FWIW, I have a (surprisingly strong) aesthetic preference for strbuf over str_buf. But I have no particular technical rationale. I end up wanting to read strbuf as a single word, in a way I wouldn't for something like raw_init or unsafe as (two of my canonical examples for a two-"word" bit of syntax).

[chandlerc]

To add at least my rationale for part of these decisions...

For str and Core.Str

• I prefer not spelling the non-owning view type Core.String because of its likely similarity with std::string
• For me, this makes str and Str not abbreviations of the word "string", but a new term of art that we are taking to provide a very concise but readable construct. Being spelled in a "string"-ish way merely allows readers to leap to likely accurate initial assumptions that this type will operate in a string-like fashion.
• Anything longer than str in the keyword syntax I think will suffer in comparison due to the forced verbosity. It's not that we couldn't afford that verbosity at all, but that any improvement brought by the syntax has to pay for itself relative to the reasonably-clear and extremely-concise str.

Together, these end up pushing me towards str and Core.Str. Deviating in the library name seems like it lessens the sense that "str" is becoming a term of art we give specific meaning to. And other syntaxes besides str seem to not be competitive given the quality of str.

For strbuf and Core.StrBuf:

• Once we've taken a term like str, it seems very useful to build on that term for the immediately complimentary construct of an owning and growable string.
• Taking "buf" to be a term of art for an owning-and-growable-contiguous-storage container seems highly appealing given the degree to which we end up wanting to push users towards such containers whenever they apply to the problem at hand.
• The shortest, most obvious combination seems to be a clear winner compared to others. Core.StringBuf doesn't seem bad, but the extra characters don't add much value having a term "str" already in the lexicon of the language.

The thing I have the least rationale for is above: I prefer strbuf over str_buf, but not for any particular reason beyond it ends up forming a single mental term for me, particularly in keyword-form. Weirdly, I don't have that feeling for the library type, and prefer StrBuf there.