From d275cf4c325c2dcb64dbae24ac2902e0a52996e3 Mon Sep 17 00:00:00 2001
From: Jonas Platte <jplatte+git@posteo.de>
Date: Tue, 23 Mar 2021 12:07:34 +0100
Subject: [PATCH 1/2] byte-concat: Delete unneeded sections

---
 text/0000-byte-concat.md | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/text/0000-byte-concat.md b/text/0000-byte-concat.md
index 56bdc5c80e3..df57082ea0c 100644
--- a/text/0000-byte-concat.md
+++ b/text/0000-byte-concat.md
@@ -51,11 +51,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
 
@@ -69,11 +64,6 @@ 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 -->
-
 # Unresolved questions
 [unresolved-questions]: #unresolved-questions
 

From 1b8ff3424c0a3eef8e29f838d8701c2d75dde30a Mon Sep 17 00:00:00 2001
From: Jonas Platte <jplatte+git@posteo.de>
Date: Wed, 26 May 2021 16:56:46 +0200
Subject: [PATCH 2/2] byte-concat: Address argument type concern

---
 text/0000-byte-concat.md | 20 +++++---------------
 1 file changed, 5 insertions(+), 15 deletions(-)

diff --git a/text/0000-byte-concat.md b/text/0000-byte-concat.md
index df57082ea0c..b58adda0fa8 100644
--- a/text/0000-byte-concat.md
+++ b/text/0000-byte-concat.md
@@ -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:
 
@@ -64,6 +54,11 @@ 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.
 
+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
 
@@ -72,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`).