Skip to content

Update byte-concat RFC #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
estebank merged 2 commits into from
May 26, 2021
Merged

Update byte-concat RFC #2

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d275cf4
byte-concat: Delete unneeded sections
jplatte Mar 23, 2021
1b8ff34
byte-concat: Address argument type concern
jplatte May 26, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 4 additions & 24 deletions text/0000-byte-concat.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,16 +25,6 @@ supported as inputs:

- byte string literals (`b"..."`)
- byte literals (`b'b'`)
- numeric literals – must fit in `u8`, any number larger than `u8::MAX` causes
a compile time error like the following:

```
error: cannot concatenate a non-`u8` literal in a byte string literal
--> $FILE:XX:YY
|
XX | concat_bytes!(256, b"val");
| ^^^ this value is larger than `255`
```
- numeric array literals – if any literal is outside of `u8` range, it will
cause a compile time error:

Expand All @@ -51,11 +41,6 @@ supported as inputs:
For example, `concat_bytes!(42, b"va", b'l', [1, 2])` evaluates to
`[42, 118, 97, 108, 1, 2]`.

# Reference-level explanation
[reference-level-explanation]: #reference-level-explanation

<!-- TODO -->

# Drawbacks
[drawbacks]: #drawbacks

Expand All @@ -69,10 +54,10 @@ string literals, like a previous revision of this RFC proposed. This would make
it hard to ensure the right output type is produced – users would have to use
hacks like adding a dummy `b""` argument to force a byte literal output.

# Prior art
[prior-art]: #prior-art

<!-- TODO -->
An earlier version of this RFC proposed to support integer literals outside of
arrays, but that was rejected since it would make the output of
`byte_concat!(123, b"\n")` inconsistent with the equivalent `concat!`
invocation.

# Unresolved questions
[unresolved-questions]: #unresolved-questions
Expand All @@ -82,8 +67,3 @@ hacks like adding a dummy `b""` argument to force a byte literal output.
support those as well (support `&[0, 1, 2]` in addition to `[0, 1, 2]`).
- What to do with string and character literals? They could either be supported
with their underlying UTF-8 representation being concatenated, or rejected.
- If supported, it would probably make sense to also support boolean literals
so `concat_bytes!()` supports all inputs `concat!()` does.
- If rejected, it would probably makes sense to also reject boolean literals
to avoid any possible confusion about their representation (`true` and
`false` vs. `1` and `0`).