CStr::from_bytes_with_nul and "nul-terminated" strings.
I think it would be more consistent to replace (deprecate and reëxport) all instances of
What do you all think? If we have rough consensus here, I'll prepare a PR for T-libs-api FCP.
null are two different things.
null is a pointer to address 0, while
nul is the name of the character with value 0.
That distinction is sometimes elided (people often say "null-terminated" rather than "nul-terminated"), but that's the distinction the API names are based on.
IIRC "NUL" is the abbreviation blessed by ASCII/Unicode for the null character. I'm not sure how I feel regarding the proposal, but a part of me likes that we can differentiate between NUL (the character) and null (the pointer).
I think a doc alias should suffice, as the two aren't quite the same as already stated.
The similarity of the established terms is unfortunate, but the distinction is important.
from_bytes_with_null would confuse me because in my mind "null" always means a null pointer.
I'm really not convinced it's worth it. The "did you mean?" hint for it should be nigh perfect if you try
error[E0425]: cannot find function `nul` in module `std::ptr`
2 | std::ptr::nul();
| ^^^ help: a function with a similar name exists: `null`
error[E0599]: no function or associated item named `from_bytes_with_null` found for struct `CStr` in the current scope
3 | CStr::from_bytes_with_null();
| function or associated item not found in `CStr`
| help: there is an associated function with a similar name: `from_bytes_with_nul`
And that seems fine to me.
Note that, according to https://www.unicode.org/Public/14.0.0/ucd/UnicodeData.txt, the name of U+0000 is "NULL", not "NUL":
0001;<control>;Cc;0;BN;;;;;N;START OF HEADING;;;;
0002;<control>;Cc;0;BN;;;;;N;START OF TEXT;;;;
Though admittedly https://www.unicode.org/Public/14.0.0/ucd/NameAliases.txt does list
NUL as an "abbreviation"
0001;START OF HEADING;control
But that does mean that
null is a perfectly correct way to refer to U+0000, not something that only means the null pointer. (Arguably the non-abbreviation is generally better, as elaborated 0580-rename-collections - The Rust RFC Book, but I suppose abbreviations do make sense in method names because
print_with_line_feed is a bit excessive compared to
Yes, but the 0-byte at the end of a
CStr is just that : a byte in a series of (otherwise non-0) bytes, not a UTF-8 encoding. Thus the naming follows the ASCII convention (or perhaps even preceding ASCII?):
||Data Link Escape
||Start of Header
||Device Control 1
||Start of Text
||Device Control 2
||End of Text
||Device Control 3
||End of Transmission
||Device Control 4
||End of Transmission Block
||End of Medium