Open imrn99 opened 2 days ago
Attention: Patch coverage is 62.32073%
with 289 lines
in your changes missing coverage. Please review.
Project coverage is 80.67%. Comparing base (
ac36dbf
) to head (f1b1135
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
An a priori comment: I am not convinced by using
Result
for the transactions. Do you have a strong argument for using this instead ofOption
?
I'm not sure to exactly which Result
you refer to. The stm
crate originally uses results to pass value through (see StmResult
), so I aligned the API with this.
In our case, we could switch the Result
to an Option
for all instances of Result<(), _>
, if that's what you mean
No, do not change, I was wondering the reason. But mimicking the stm crate is a pretty valid one.
I split the original
link_and_sew.rs
file into two modules:links
andsews
, each having submodules for dim1 and dim2.there are now 3 and 2 variants for (un)sew and (un)link methods respectively. Here are two tables summarizing their differences (for
sew
andlink
, complementary methods follow the same pattern):try_<DIM>_sew
<DIM>_sew
force_<DIM>_sew
<DIM>_link
force_<DIM>_sew
TODO: implement the
try_
variants. I want to do it in a separate PR because I will modify the attribute storage traits to follow a similar pattern. I'm guessing do it here would double the size of the PR, and unnecessarily mix unrelated changes