Consider adding CString/*const i8 literals

[canndrew]

There's already b"foo" syntax for [u8] literals and I've seen talk of adding s"foo" for String literals (perhaps through a syntax extension). If we're going down that path we could also add c"foo" syntax which could be either a CString or a *const i8. This would be useful for interacting with foreign C code. Currently, to call a C function with a string constant I'm using

foo(b"my string\0".as_ptr() as *const i8)

But that's a little cumbersome (and error-prone if I accidentally leave the NUL off).

[thestinger]

CString is not for static C strings, it's an RAII wrapper for malloc/free buffers with a terminating \0. It's not part of the language so it isn't going to get literal sugar and should really just be removed from the standard libraries completely.

I don't think using C strings should be encouraged because they're incapable of storing text (UTF-8 has inner NUL) and binary correctly so the use cases where they work are very niche. We've already got the path case covered with Path and that's 99% of valid reasons to use C strings. Anything making use of them is always going to require unsafe code anyway so I don't see a problem with needing to use \0 when you're doing something that's ugly in the first place.

cc @nick29581, this should be moved to the RFC repository

[mahkoh]

It could not be *const i8 because c_char is not i8 in general.

[canndrew]

I don't think there's much risk of encouraging people to use *const i8s instead of strs and Strings. They don't play nicely with the rest of the libraries and can only be used inside of unsafe blocks. The reason to do it would purely be to make writing FFI code a bit neater and less error-prone. And it's not like the c-prefix is being used for anything else.

[rust-highfive]

This issue has been moved to the RFCs repo: rust-lang/rfcs#400