Skip to content

Commit 4a5566e

Browse files
committed
Clean up whitespace
1 parent 33cf795 commit 4a5566e

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

text/3809-derive-from.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -180,7 +180,7 @@ The question then becomes what would be generated under this design when the str
180180

181181
- We could either generate `From<T> for Type`, which would be compatible with this RFC. It would also be slightly inconsistent though, as it would generate something different only for the case with a single field.
182182
- This is how the `derive_more::From` macro behaves.
183-
- Or, we could generate `From<(T, )> for Type`, which would be consistent with the logic of generating `From<tuple>`. However, single-field tuples are not idiomatic and it would be awkward having to write e.g. `(value, ).into()` to make use of the impl.
183+
- Or, we could generate `From<(T, )> for Type`, which would be consistent with the logic of generating `From<tuple>`. However, single-field tuples are not idiomatic and it would be awkward having to write e.g. `(value, ).into()` to make use of the impl.
184184

185185
I think that the second approach is not a good idea, and I find it unlikely that we would want to use it.
186186

0 commit comments

Comments
 (0)