Update proposal.md

Author: lemire

cppcon2025/proposal.md

@@ -22,19 +22,75 @@ Thankfully, C++ might soon be getting reflective metaprogramming ([PR2996](https
 
 *You'll not be held to this—we understand that this is a snapshot in time.*
 
-- JSON, performance and safety issues
-- C++20 elements: concepts, tag_invoke, constexpr
-- C++26 reflective metaprogramming: modest introduction
-- How we made use of it: serialization and deserialization
-- Quick perf analysis for our first working prototype (hint: it was not super fast!)
-- Optimizing the code: what made a difference!
-- Serialization benchmarks!
-- Deserialization benchmarks: Rust Serde and others.
-- Safety: Is it improved?
-- Downside: How challenging is reflective metaprogramming?
-- Downside: slower builds? (with numbers!)
-- Downside: difficult error messages (with examples!)
 
+#### JSON, performance and safety issues
+- **Why JSON matters**: Brief recap of JSON’s ubiquity—web APIs, config files, data interchange—and its intuitive appeal (e.g., `{"age": 5, "name": "Daniel"}`).
+- **Performance bottlenecks**: Parsing complexity (string handling, nested structures), number parsing and serialization, serialization overhead, and the cost of manual mapping in C++.
+- **Safety pitfalls**: Type mismatches, unexpected input (e.g., broken Unicode), and lack of compile-time guarantees in traditional C++ JSON libraries.
+- **Motivation**: Contrast with languages like Rust (serde), Go or Python, where JSON handling is ergonomic—why C++ lags behind.
+
+#### C++20 elements: concepts, tag_invoke, constexpr
+- **Concepts**: How they enable cleaner, more constrained interfaces.
+- **tag_invoke**: A customization point mechanism—how it simplifies generic serialization/deserialization hooks with less boilerplate.
+- **constexpr**: Leveraging compile-time computation for precomputed parsing or formatting logic.
+- **Setup for reflection**: These features lay the groundwork for metaprogramming but fall short of full automation.
+
+#### C++26 reflective metaprogramming: modest introduction
+- **What it is**: Brief explanation of reflection (PR2996)—introspecting C++ types at compile time (e.g., fields of a struct, their names/types).
+- **Why it’s a game-changer**: No more manual mapping of JSON to structs; the compiler "knows" your data structures.
+- **Bloomberg LLVM fork**: Quick note on the experimental implementation—why we used it and its current state.
+- **Simple example**: Show a struct `Person { int age; std::string name; }` and how reflection exposes it for JSON.
+
+#### How we made use of it: serialization and deserialization
+- **Core idea**: Reflection auto-generates code to map JSON to/from C++ structs (e.g., `Person` to `{"age": 5, "name": "Daniel"}`).
+- **Serialization**: Walking struct fields via reflection, emitting JSON strings at compile time where possible.
+- **Deserialization**: Parsing JSON tokens and populating structs, with type-safe error handling.
+- **Implementation details**: High-level overview—lexer, parser, and reflection-driven binder.
+
+#### Quick perf analysis for our first working prototype (hint: it was not super fast!)
+- **Why it was slow**: Naive string handling and unoptimized reflection overhead.
+- **Lessons learned**: Early profiling showed us where to focus—set the stage for optimization.
+
+#### Optimizing the code: what made a difference!
+- **Key wins**: Prepare keys at compile-time, SIMD for string ops.
+- **Anecdote**: Profiling experience is so-so.
+- **Result**: Leap to gigabytes per second.
+
+#### Serialization benchmarks!
+- **Setup**: Describe test data and hardware.
+- **Numbers**: Compare our implementation to alternatives 
+- **Visuals**: It is really fast! (But could be faster)
+
+#### Deserialization benchmarks: Rust Serde and others
+- **Setup**: Describe test data (two complex JSON files) and hardware.
+- **Head-to-head**: Your lib vs. serde (Rust), nlohmann/json (C++), and others.
+- **Results**: We beat the alternatives  (reflection + C++ control).
+- **System-dependent**: Processor type matters.
+
+#### Safety: Is it improved?
+- **Compile-time checks**: Reflection catches type mismatches before runtime.
+- **Error handling**: Graceful fallback for malformed JSON, with clear diagnostics.
+- **Trade-offs**: More safety than handwritten code, but not foolproof (e.g., runtime edge cases).
+
+#### Downside: How challenging is reflective metaprogramming?
+- **Learning curve**: Syntax and concepts are new—takes time to grok.
+- **Tooling**: Debugging reflection code is tricky.
+- **Audience hook**: "It’s like template metaprogramming’s wild cousin—powerful but untamed."
+
+#### Downside: Slower builds? (with numbers!)
+- **Data**: Share compile-time costs.
+- **Why**: Reflection generates lots of code; LLVM fork isn’t optimized yet.
+- **Mitigation**: Precompiled headers or caching strategies you explored.
+
+#### Downside: Difficult error messages (with examples!)
+- **Reality**: Reflection errors can be verbose and cryptic.
+- **Example**: Real errors one might encounter.
+- **Hope**: Compiler vendors will improve diagnostics as reflection matures
+
+#### Conclusion
+- **How close?**: Should you try it today?
+- **How beneficial?**: How much help can you expect?
+- **How impactful?**: How much of a difference will it make?
 
 ## Preferred session length