Skip to content

Manually apply fixes from PR 81 #85

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
jbcoe merged 1 commit into from
May 12, 2026
Merged

Manually apply fixes from PR 81 #85

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
23 changes: 9 additions & 14 deletions DRAFT.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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>
Expand All @@ -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>
Expand Down Expand Up @@ -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);
};
Expand Down Expand Up @@ -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

Expand Down Expand Up @@ -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]).
Expand Down
Loading