[kreco]

I'm not sure I agree with "impossible to change".

It's 2026, to this date I cannot use standard library/api, to open a file with utf-8 filename without a null terminating string.

When you want to talk to the OS you constantly face the need to had unnecessary overhead (allocation due to string convertion, strlen).

The OS itself does not prevent anything from having those standard "no overhead" API.

However, it's pretty clear that nobody cares to define some new sane interface and nobody care to deprecate old ones.

That would include both API and ABI.

[phicoh]

Maybe because the performance gain is just not there. Adding support for string with explicit length everywhere is a huge amount of work. And then the question is whether such a string is like a Rust slice or something else.

And then the gain is close to zero because most filenames are short enough that there is almost no gain.

[kreco]

The mental overhead is pretty significant.

You need to do weird string operations, you have certainly a class somewhere that needs to append a zero to then end of a buffer, and exclusively use the class for thw filename. You can't just toss a contiguous number of bytes you to convert it first.

Every single piece of software that need to interact with the file system needs to deal with this.

I'm not asking about a new string type. I'm asking to be able to be free from null terminating string.

You only need to provide a length.