From 30e5661d74787c834f2100a3ead909491ace6e8a Mon Sep 17 00:00:00 2001 From: Jul Lang Date: Sat, 28 Feb 2026 23:20:50 +0100 Subject: [PATCH] fix small typo in area calculation tutorial --- docs/tutorials/area-calculation/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/tutorials/area-calculation/index.md b/docs/tutorials/area-calculation/index.md index 25ef894..b0b59c5 100644 --- a/docs/tutorials/area-calculation/index.md +++ b/docs/tutorials/area-calculation/index.md @@ -73,7 +73,7 @@ pub struct ComplexRectangle { As the context grows, it becomes significantly more tedious to call a method like `rectangle_area`, even if we don't care about using other methods. We would still need to first construct a `ComplexRectangle` with most of the fields having default value, before we can call `rectangle_area`. -Furthermore, a concrete context definition also limits how it can be extended. Suppose that a third party application now wants to use the provided methods like `scaled_rectangle_area`, but also wants to store the rectangles in a *3D space*, it would be tough to ask the upstream project to introduce a new `pos_z` field, which can potentially break many existing code. In the worst case, the last resort for extending the context is to fork the entire project to make the changes. +Furthermore, a concrete context definition also limits how it can be extended. Suppose that a third party application now wants to use the provided methods like `scaled_rectangle_area`, but also wants to store the rectangles in a *3D space*, it would be tough to ask the upstream project to introduce a new `pos_z` field, which can potentially break a lot of existing code. In the worst case, the last resort for extending the context is to fork the entire project to make the changes. Ideally, what we really want is to have some ways to pass around the fields in a context *implicitly* to functions like `rectangle_area` and `scaled_rectangle_area`. As long as a context type contains the required fields, e.g. `width` and `height`, we should be able to call `rectangle_area` on it without needing to implement it for the specific context. @@ -83,4 +83,4 @@ We have now identified the two core limitations of conventional Rust approaches: In the first tutorial, Context-Generic Functions, we will see how the `#[cgp_fn]` macro and `#[implicit]` arguments address both of these limitations at once, allowing us to write a single `rectangle_area` function that works cleanly across any context that provides the required fields. We will also explore how CGP functions can import each other via `#[uses]`, and take an optional look at how the macro desugars into plain Rust traits under the hood. -In the second tutorial, Static Dispatch, we will introduce a second shape — the circle — and define a unified `CanCalculateArea` trait as a common interface across all shapes. We will run into Rust's coherence restrictions when trying to provide blanket implementations, and then resolve this with CGP's `#[cgp_component]` macro and named providers. Finally, we will see how `delegate_components!` wires contexts to providers at compile time, and how higher-order providers allow provider implementations to compose generically, with zero runtime overhead. \ No newline at end of file +In the second tutorial, Static Dispatch, we will introduce a second shape — the circle — and define a unified `CanCalculateArea` trait as a common interface across all shapes. We will run into Rust's coherence restrictions when trying to provide blanket implementations, and then resolve this with CGP's `#[cgp_component]` macro and named providers. Finally, we will see how `delegate_components!` wires contexts to providers at compile time, and how higher-order providers allow provider implementations to compose generically, with zero runtime overhead.