Skip to content

Commit df9bd28

Browse files
committed
Add c'…' idea.
1 parent 9fdd8f1 commit df9bd28

File tree

1 file changed

+12
-0
lines changed

1 file changed

+12
-0
lines changed

text/3348-c-str-literal.md

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -78,6 +78,15 @@ Interactions with string related macros:
7878

7979
We already have a type called `CStr` for this, so `c` seems consistent.
8080

81+
- Also add `c'…'` as [`c_char`](https://doc.rust-lang.org/stable/core/ffi/type.c_char.html) literal.
82+
83+
It'd be identical to `b'…'`, except it'd be a `c_char` instead of `u8`.
84+
85+
This would easily lead to unportable code, since `c_char` is `i8` or `u8` depending on the platform. (Not a wrapper type, but a direct type alias.)
86+
E.g. `fn f(_: i8) {} f(c'a');` would compile only on some platforms.
87+
88+
An alternative is to allow `c'…'` to implicitly be either a `u8` or `i8`. (Just like integer literals can implicitly become one of many types.)
89+
8190
# Drawbacks
8291
[drawbacks]: #drawbacks
8392

@@ -95,7 +104,10 @@ Interactions with string related macros:
95104
# Unresolved questions
96105
[unresolved-questions]: #unresolved-questions
97106

107+
- Also add `c'…'` C character literals? (`u8`, `i8`, `c_char`, or something more flexible?)
108+
98109
- Should we make `&CStr` a thin pointer before stabilizing this? (If so, how?)
110+
99111
- Should the (unstable) [`concat_bytes` macro](https://github.com/rust-lang/rust/issues/87555) accept C string literals? (If so, should it evaluate to a C string or byte string?)
100112

101113
# Future possibilities

0 commit comments

Comments
 (0)