Clarifications in maybealwaysfirst comment

core-wg · Mar 2, 2024 · 28a0f4e · 28a0f4e
1 parent b270878
commit 28a0f4e
Showing 1 changed file with 2 additions and 2 deletions.
diff --git a/draft-bormann-core-responses.md b/draft-bormann-core-responses.md
@@ -201,9 +201,9 @@ These rules generalize {{Sections 8.3 (Protecting the Response) and 8.4
 
 [^maybealwaysfirst]: CA: We could also just mandate the "either the first or never" behavior.
 
-  It is unclear why one would save the efficient response,
+  It is unclear why one would delay sending the one response that has the least overhead,
   but that may be lack of imagination.
-  An affine type system can make this doable in a safe way.
+  An affine type system (where instances can not generally be duplicated and are used at most once) can make this doable in a safe way.
   In the end it's a tradeoff between implementer flexibility and specification simplicity.
 
 * In 8.4 between steps 5 and 6,