https://github.com/rust-lang/rust/pull/117472
Soon you will be able to write c"Hello" in rust and get a valid UTF-8 encoded *NUL-terminated* string. This is amazing for people who work with C APIs.
https://github.com/rust-lang/rust/pull/117472
Soon you will be able to write c"Hello" in rust and get a valid UTF-8 encoded *NUL-terminated* string. This is amazing for people who work with C APIs.
@thejpster I'm conflicted about this. Sure it's nice ergonomics, but `cstr!(...)` wasn't that bad, and it feels like it's giving a foreign language construct more weight in the language than it should have. Yeah it's used widely, but so is `hexlit!(...)`, and where do we stop.
@chrysn That's THE STANDARD for interfacing with an OS. Any OS that attempts to be interoperable with the corpus of existing software rather than going off and doing its own random thing. Attempting to characterize that as "just" "unix based OSs" is ideologuerry.
@dalias I'm not arguing its exclusion, but that it's getting this prominent a place in the language instead of a namespaced extension point.
The point on system interfaces is true for Unix based OSes, but on embedded and WASM systems I don't know of any interfaces where nul-terminated strings are meaningful.
@chrysn @thejpster It's not just "foreign language" but a fundamental part of the contract with system interfaces and lots of inter-systems interfaces. No good reason for excluding it except anti-C ideologuerry.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.