You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: benchmarks/runtime/README.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,8 +6,8 @@ This is a collection of runtime benchmarks for the code generated by `bon` crate
6
6
7
7
If you'd like to run the benchmarks yourself, first you need to install the following:
8
8
9
-
-`Valgrind`. Its `cachegrind` component is used by [`iai`](https://github.com/bheisler/iai) benchmark to display the instruction counts and cache/RAM hits.
10
-
-`cargo-asm`. It's used to get the resulting assembly code for the benchmarked functions.
9
+
-`Valgrind`. Its `cachegrind` component is used by [`iai`](https://github.com/bheisler/iai) benchmark to display the instruction counts and cache/RAM hits.
10
+
-`cargo-asm`. It's used to get the resulting assembly code for the benchmarked functions.
11
11
12
12
If you are on Ubuntu or Debian, just run the following commands to install the dependencies:
I recommend you to check out the ["Into Conversions In-Depth"](../guide/patterns/into-conversions-in-depth) especially because it's highly related to one of the breaking changes that we'll review below.
68
68
@@ -222,8 +222,8 @@ Also, huge thank you for 500 stars ⭐ [on Github](https://github.com/elastio/bo
222
222
223
223
You can leave comments for this post on the platform of your choice:
Copy file name to clipboardExpand all lines: website/src/blog/bon-builder-v2-1-release.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,8 +29,8 @@ This optimization covers only the code produced by expanding the [`#[bon::builde
29
29
30
30
The `#[builder]` macro now [benefits](https://github.com/elastio/bon/blob/88529337e261e8ca11268b2d4759f9372d802e45/bon/src/private/mod.rs#L8-L32) from the [`#[diagnostic::on_unimplemented]`](https://doc.rust-lang.org/nightly/reference/attributes/diagnostics.html#the-diagnosticon_unimplemented-attribute) attribute. It now generates a readable compile error with additional context for debugging in the following cases:
31
31
32
-
-Forgetting to set a required member.
33
-
-Setting the same member twice (unintentional overwrite).
32
+
- Forgetting to set a required member.
33
+
- Setting the same member twice (unintentional overwrite).
34
34
35
35
Let's see this in action in the following example of code:
36
36
@@ -249,8 +249,8 @@ Also, a huge thank you for 600 stars ⭐ [on Github](https://github.com/elastio/
249
249
250
250
You can leave comments for this post on the platform of your choice:
Copy file name to clipboardExpand all lines: website/src/blog/bon-builder-v2-3-release.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,8 +31,8 @@ As an example, suppose we have a `Treasure` struct with `x` and `y` coordinates
31
31
32
32
To do that we can use the `#[builder(start_fn)]` attribute. There are two contexts where we can place it, and they both have a different meaning:
33
33
34
-
-[Top-level `#[builder(start_fn = ...)]`](../reference/builder/top-level/start_fn) - configures the name of the starting function and optionally its visibility
35
-
-[Member-level `#[builder(start_fn)]`](../reference/builder/member/start_fn) - configures the member to be a positional parameter on the starting function
34
+
-[Top-level `#[builder(start_fn = ...)]`](../reference/builder/top-level/start_fn) - configures the name of the starting function and optionally its visibility
35
+
-[Member-level `#[builder(start_fn)]`](../reference/builder/member/start_fn) - configures the member to be a positional parameter on the starting function
36
36
37
37
We'll want to use both of these attributes in our example to give a better name for the starting function that describes its inputs and configure `x` and `y` as positional parameters on the starting function as well.
38
38
@@ -146,8 +146,8 @@ Bon's goal is to empower everyone to build beautiful APIs with great flexibility
146
146
147
147
You can leave comments for this post on the platform of your choice:
`typed-builder` uses a tuple to represent the typestate with the following rules:
94
94
95
-
-The number of items in the tuple corresponds to the number of fields in the struct.
96
-
-`()` item in the tuple represents a field that was not set yet.
97
-
-`(T,)` item in the tuple represents a field that was already set; `T` is the type of that field.
95
+
- The number of items in the tuple corresponds to the number of fields in the struct.
96
+
-`()` item in the tuple represents a field that was not set yet.
97
+
-`(T,)` item in the tuple represents a field that was already set; `T` is the type of that field.
98
98
99
99
`typed-builder`'s approach violates privacy by exposing the internals of the struct:
100
100
101
-
-🚨 Types of the struct's fields
102
-
-🚨 Order of struct's fields' declaration
103
-
-🚨 Number of struct's fields
101
+
- 🚨 Types of the struct's fields
102
+
- 🚨 Order of struct's fields' declaration
103
+
- 🚨 Number of struct's fields
104
104
105
105
If the users of `typed-builder` ever write a type annotation for the builder, then their code becomes fragile to any changes in the struct's private fields.
106
106
@@ -110,8 +110,8 @@ Starting with this release, `bon` uses a layered typestate that doesn't mention
110
110
111
111
However, `bon`'s signature depends on the order of setter calls. For example:
112
112
113
-
-if you call `x1(1).x2(2)`, the type state is `SetX2<SetX1>`
114
-
-if you call `x2(2).x1(1)`, the type state is `SetX1<SetX2>`
113
+
- if you call `x1(1).x2(2)`, the type state is `SetX2<SetX1>`
114
+
- if you call `x2(2).x1(1)`, the type state is `SetX1<SetX2>`
115
115
116
116
This is still better than the tuple approach. The setter calls order is controlled by the caller, so this isn't private to them anyway.
117
117
@@ -292,11 +292,11 @@ struct Example {}
292
292
293
293
There were many new attributes added to override the visibility and the documentation of various items generated by the builder macros:
Copy file name to clipboardExpand all lines: website/src/blog/the-weird-of-function-local-types-in-rust.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -320,8 +320,8 @@ It means, that if we want to support local items in our macro we just can't use
320
320
321
321
The core problem is the conflict:
322
322
323
-
-We want to make the builder's fields private, so we need to define the builder struct inside of a child module.
324
-
-We want to reference types from the surrounding scope in the builder's fields, including local items, so we can't define the builder struct inside the child module.
323
+
- We want to make the builder's fields private, so we need to define the builder struct inside of a child module.
324
+
- We want to reference types from the surrounding scope in the builder's fields, including local items, so we can't define the builder struct inside the child module.
325
325
326
326
This is the problem that I found in `buildstructor`. The only way to solve this is to make a compromise, which I did when implementing [`#[derive(bon::Builder)]`](../guide/overview). The compromise is not to use a child module, and obfuscate the private fields of the builder struct with leading `__` and `#[doc(hidden)]` attributes to make it hard for the user to access them (even though not physically impossible).
0 commit comments