A big downside is that you you can't easily take ownership of an existing buffer and treat it as this string type.

string s;

char some_buf[];

string_take(&s, some_buf, some_capacity);

Also you would of course never dynamically allocate string structs, just the data member if needed.

The str type you mention is a nice feature, and in the future when I will have switched to Rust or whatever, I might use it to write my programs in 5 lines less.

While in C I have to use C's "slice" type: char x[] = "Hello". I know it's not quite as good since if I was to pass this around, I would have to make a pointer + length representation for this. If I needed it, it can be automatized from string literals: struct String(const char *buffer, size_t size); #define STRING(lit) (String){lit "", sizeof lit - 1}. Or char buffer[256]; my_api(buffer, sizeof buffer);

For the few situtations where string manipulation is required, it's just not a real problem.

WUFFS doesn't have strings. That's what a language which doesn't have strings looks like, you can't write "Hello, world" in WUFFS because it involves Strings, which WUFFS doesn't have, and I/O, which WUFFS also doesn't have.

A pretence that C doesn't have strings because it lacks a concrete string type in the language itself also seems like you'd be claiming C++ doesn't have strings, Zig doesn't have strings, and Rust came pretty close to not having strings (for a while it was mooted to make Rust's str just a slice [u8] but today Rust does bless str as a distinct type even though e.g. &str and &[u8] aren't very different)

I understand that this is... obscure for some reason and I'm not saying it never happens, but let's be realistic....

Thanks.

If I'm dealing with lots of string manipulations I usually create a struct with a count and an alloc size and a char* pointer and write init, cleanup, extend, and append functions specific for it and use that as a string type. It's less of a mental load for me to deal with reallocating an array and keeping count and alloc updated correctly once than it is knowing that character arrays are being recounted all the time and worrying about exactly where the '\0' is going to end up and if my buffer is large enough for every string I'm dealing with.

If you think it's necessary, it's very easy to make an argument that you'd have to have a generic type for slices of any type. (Actually, more so than strings, since C is just not a language for domains with a focus on strings).

Now, whether you think a language must have a generic slice type or not, C is simply not the language where you can fit that in.

I know you can find bolt ons, but they aren't terribly useful since no 3rd party libraries use them. You have to resort to stuff like antirez's sds.

If you get it right and hide all of the complexity from the user then it's not quite as bad, although undoubtedly confusing the first few times someone inspects it in their debugger.

If you want to "join together" strings data and printf/snprintf isn't convenient enough, go ahead and use different tool. But don't act like computers can natively compute the concatenation of two string buffers, and offer you the result into your expecting hands. On a lower level, everything needs to be stored in memory somewhere, and if "just somewhere in a heap allocation" is good enough for your purposes, use a different language but don't expect best performance nor simplicity.

Why can't we just have some nice structures instead?

  struct memory {
      size_t size;
      unsigned char *address;
  };

  enum text_encoding { TEXT_ENCODING_UTF8, /* ... */ };

  struct text {
      enum text_encoding encoding;
      struct memory bytes;
  };

C doesn't have strings is because there wasn't a well accepted library for them at the precambrian time it was being designed. Otherwise it would've, not out of some ideological fit-for-purpose nonsense. It was supposed to be a high level language, as high as they could go with systems being as crap as they were back then.