summaryrefslogtreecommitdiffstats
path: root/vendor/partial_ref/README.md
diff options
context:
space:
mode:
Diffstat (limited to 'vendor/partial_ref/README.md')
-rw-r--r--vendor/partial_ref/README.md109
1 files changed, 109 insertions, 0 deletions
diff --git a/vendor/partial_ref/README.md b/vendor/partial_ref/README.md
new file mode 100644
index 000000000..1b32c91b2
--- /dev/null
+++ b/vendor/partial_ref/README.md
@@ -0,0 +1,109 @@
+# partial_ref - Type checked partial references.
+
+[![crates.io](https://img.shields.io/crates/v/partial_ref.svg)](https://crates.io/crates/partial_ref)
+[![docs.rs](https://docs.rs/partial_ref/badge.svg)](https://docs.rs/partial_ref)
+![](https://img.shields.io/crates/l/partial_ref.svg)
+
+This crate provides type checked partial references for rust. Type checked
+partial references are one solution to solve
+[interprocedural borrowing conflicts][interprocedural-conflicts].
+
+## Soundness Issues
+
+Previous versions had a potential soundness issue regarding internal address
+computations. This was not clear at the time I wrote the first version. Later
+it became clear, but there was no viable alternative, so I added a warning to
+this readme. Now with [`addr_of`] and [`addr_of_mut`] being stabilized since
+Rust 1.51, I updated the implementation to avoid this issue.
+
+[`addr_of`]:https://doc.rust-lang.org/std/ptr/macro.addr_of.html
+[`addr_of_mut`]:https://doc.rust-lang.org/std/ptr/macro.addr_of_mut.html
+
+## Deprecation
+
+I wrote this library for its use in [Varisat]. After making extensive use of
+this, I am not convinced that overall this is a good approach to solve
+interprocedural borrowing conflict issues. In particular I think the
+implementation is way too complex for the functionality it provides.
+
+I am currently working on a new version of this library that implements the
+same essential idea using a slightly simpler API and a much simpler
+implementation. In general I would recommend trying alternative workarounds to
+avoid interprocedural borrowing conflicts, but if you come to the conclusion
+that partial references are the best solution for your use case, my advice
+would be to wait for the new version of this library to be released.
+
+[varisat]: https://crates.io/crates/varisat
+
+## Example
+
+```rust
+use partial_ref::*;
+
+part!(pub Neighbors: Vec<Vec<usize>>);
+part!(pub Colors: Vec<usize>);
+part!(pub Weights: Vec<f32>);
+
+#[derive(PartialRefTarget, Default)]
+pub struct Graph {
+ #[part(Neighbors)]
+ pub neighbors: Vec<Vec<usize>>,
+ #[part(Colors)]
+ pub colors: Vec<usize>,
+ #[part(Weights)]
+ pub weights: Vec<f32>,
+}
+
+let mut g = Graph::default();
+let mut g_ref = g.into_partial_ref_mut();
+
+g_ref.part_mut(Colors).extend(&[0, 1, 0]);
+g_ref.part_mut(Weights).extend(&[0.25, 0.5, 0.75]);
+
+g_ref.part_mut(Neighbors).push(vec![1, 2]);
+g_ref.part_mut(Neighbors).push(vec![0, 2]);
+g_ref.part_mut(Neighbors).push(vec![0, 1]);
+
+pub fn add_color_to_weight(
+ mut g: partial!(Graph, mut Weights, Colors),
+ index: usize,
+) {
+ g.part_mut(Weights)[index] += g.part(Colors)[index] as f32;
+}
+
+let (neighbors, mut g_ref) = g_ref.split_part_mut(Neighbors);
+let (colors, mut g_ref) = g_ref.split_part(Colors);
+
+for (edges, &color) in neighbors.iter_mut().zip(colors.iter()) {
+ edges.retain(|&neighbor| colors[neighbor] != color);
+
+ for &neighbor in edges.iter() {
+ add_color_to_weight(g_ref.borrow(), neighbor);
+ }
+}
+```
+
+## Documentation
+
+ * [Reference and Tutorial][docs]
+
+## License
+
+The partial_ref source code is licensed under either of
+
+ * Apache License, Version 2.0
+ ([LICENSE-APACHE](LICENSE-APACHE) or
+ http://www.apache.org/licenses/LICENSE-2.0)
+ * MIT license
+ ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)
+
+at your option.
+
+### Contribution
+
+Unless you explicitly state otherwise, any contribution intentionally submitted
+for inclusion in partial_ref by you, as defined in the Apache-2.0 license,
+shall be dual licensed as above, without any additional terms or conditions.
+
+[docs]:https://docs.rs/partial_ref
+[interprocedural-conflicts]:http://smallcultfollowing.com/babysteps/blog/2018/11/01/after-nll-interprocedural-conflicts/