Not just security issues, it also makes substrings zero copy.

That can be problematic, too.

If your language has a garbage collector, it may mean tiny substrings keep huge strings alive. Java moved away from using slices (https://dzone.com/articles/changes-stringsubstring-java-7), I think for that reason.

If your language isn’t garbage collected, it can cause problems if the substring must outlive the string it was extracted from. That means that, for some functions, you’ll have to decide whether to return the slice or make the copy.

(In Rust, that means the slice has a different ‘type’ (not sure what they call it), that of a string whose lifetime is bound to the original string, and the compiler will check that you won’t make the mistake of having the slice outlive it’s source)

How huge typical strings are that this is a problem? It could be a problem for arrays but seems unlikely for strings.

Some strings start live as part of multi-megabyte text files that get slurped in. Happened quite a bit with HTML/XML parsers. Workaround was to do new String(s.substring(…)) about everywhere. Real world case (with few details) at https://stackoverflow.com/questions/10951812/java-not-garbag....

Also, using slices doesn’t come for free; it makes all String objects larger because, apart from the reference to the underlying character array, an offset and length must be kept around.

Yep, all good points!

(And yeah, you're right about Rust too; string slices are a different type than owned strings.)

It also makes it possible to have nulls inside a string.

This is usually a bad idea, FWIW.

I mean, I wasn't trying to suggest you intentionally inject nulls in your strings for no reason! But that doesn't mean your data types should unexpectedly break if this ends up happening...

Generally my policy with std::string and NULs is "don't, ever" because someone is going to call c_str() on it and pass it to a C API, and bad things are going to happen. If you need to embed \0, then use std::vector<char>. Of course, you do get the slight benefit that in the cases where you don't call C APIs you won't have bad things happen, but I wouldn't could on that.

Again, this isn't about whether you go out of your way to insert it, but about whether the data type should be able to handle it regardless.

I'll just leave this here: https://youtu.be/5dhSN9aEljg

Zig as of 0.6.0 supports both sentinels and length.