From c0bdbdad6ca51c2060416b14c77ca58db8308dac Mon Sep 17 00:00:00 2001
From: "Jonathan B. Coe" <jonathanbcoe@gmail.com>
Date: Tue, 12 May 2026 13:52:58 +0100
Subject: [PATCH] Manually apply fixes from PR 81

---
 DRAFT.md | 23 +++++++++--------------
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/DRAFT.md b/DRAFT.md
index 60d9976..8fb415e 100644
--- a/DRAFT.md
+++ b/DRAFT.md
@@ -76,7 +76,7 @@ support for static structural typing through concepts, it lacks a corresponding
 mechanism for runtime abstractions. In practice, this gap is addressed through
 the widespread use of type-erasure.
 
-Standard librarie facilities such as `std::function`, `std::any`,
+Standard library facilities such as `std::function`, `std::any`,
 `std::ranges::any_view` and the many other type-erasure based solutions demonstrate
 that the need for dynamic structural interfaces is both real and recurring. However,
 these solutions are implemented in an ad-hoc manner, requiring significant boilerplate
@@ -113,7 +113,7 @@ so long as that type is a structural sub-type of `T`.
 
 Like `polymorphic`, `protocol` supports deep-copies, const propagation and
 custom allocators. Like `polymorphic`, `protocol` has a valueless state after
-after being moved from to allow move construction and move assignment without
+being moved from to allow move construction and move assignment without 
 dynamic memory allocation.
 
 Where `polymorphic<T>` is owning, `T*`, or `const T*` can be used as a
@@ -219,7 +219,7 @@ class protocol<I, Allocator=std::allocator<void>> {
 ```
 
 ```c++
-template <typename Allocator>
+template <>
 class protocol_view<I> {
     // Constructor from any mutable conforming object.
     template <typename T>
@@ -246,7 +246,7 @@ class protocol_view<I> {
 ```
 
 ```c++
-template <typename Allocator>
+template <>
 class protocol_view<const I> {
     // Constructor from any const conforming object.
     template <typename T>
@@ -328,12 +328,12 @@ struct MutatingFunction {
 template <typename R, typename... Args>
 struct MoveOnlyMutatingFunction {
     // Deleted copy constructor and copy assignment.
-    MoveOnlyFunction(const MoveOnlyFunction&) = delete;
-    MoveOnlyFunction& operator=(const MoveOnlyFunction&) = delete;
+    MoveOnlyMutatingFunction(const MoveOnlyMutatingFunction&) = delete;
+    MoveOnlyMutatingFunction& operator=(const MoveOnlyMutatingFunction&) = delete;
 
     // Defaulted move constructor and move assignment.
-    MoveOnlyFunction(MoveOnlyFunction&&) = default;
-    MoveOnlyFunction& operator=(MoveOnlyFunction&&) = default;
+    MoveOnlyMutatingFunction(MoveOnlyMutatingFunction&&) = default;
+    MoveOnlyMutatingFunction& operator=(MoveOnlyMutatingFunction&&) = default;
 
     R operator()(Args&&... args);
 };
@@ -465,7 +465,7 @@ Equality or comparison operators are not part of the core functionality of `prot
 
 This proposal is a library extension. It requires language support for code
 injection from static reflection and the addition of a new standard library
-header `<protocol>`."
+header `<protocol>`.
 
 ## Polls
 
@@ -503,11 +503,6 @@ properties required by this proposal.
 [py_cppmodel] _Python wrappers for clang's parsing of C++ to simplify AST
 analysis_. <https://github.com/jbcoe/py_cppmodel>
 
-.html>
-
-[py_cppmodel] _Python wrappers for clang's parsing of C++ to simplify AST
-analysis_. <https://github.com/jbcoe/py_cppmodel>
-
 ## Appendix A: Illustrative Implementation
 
 This appendix provides an illustrative example of the proposed implementation using static reflection and code injection. Identifiers in UPPER CASE denote hypothetical reflection primitives or language features that are not currently part of the C++26 reflection proposal ([P2996R13]).