From ff3122b8148e398297a11c4d4afbb355e95c1760 Mon Sep 17 00:00:00 2001 From: smol <107521333+a-tiny-kirin@users.noreply.github.com> Date: Sun, 16 Jun 2024 04:06:38 +0000 Subject: [PATCH] (automated) deploy from commit 1bd6b79f8bf34065718057d4d98a06fc0c8dc9e7 --- src/wiwi/with_cloned/mod.rs.html | 52 ++++++++++++++----------- wiwi/index.html | 2 +- wiwi/macro.with_cloned.html | 48 ++++++++++++----------- wiwi/with_cloned/index.html | 2 +- wiwi/with_cloned/macro.with_cloned.html | 48 ++++++++++++----------- 5 files changed, 84 insertions(+), 68 deletions(-) diff --git a/src/wiwi/with_cloned/mod.rs.html b/src/wiwi/with_cloned/mod.rs.html index 8da5a1bf4..17d5c35dd 100644 --- a/src/wiwi/with_cloned/mod.rs.html +++ b/src/wiwi/with_cloned/mod.rs.html @@ -184,6 +184,10 @@ 184 185 186 +187 +188 +189 +190 
/// Executes code with cloned values, so the executed code
 /// can take ownership of the value without moving the original
 ///
@@ -240,10 +244,10 @@
 /// assert_eq!(*shared_data.lock().unwrap(), 420);
 /// ```
 ///
-/// ... this is not great, since you'd have to use `_shared_data` to refer to
-/// the cloned value.
+/// ... this is not great, since you'd have to use `_shared_data` with an
+/// underscore to refer to the cloned value.
 ///
-/// But alternatively, it can be done with a temporary scope:
+/// It can also be done with a temporary scope:
 ///
 /// ```
 /// # use std::sync::{ Arc, Mutex };
@@ -262,14 +266,16 @@
 /// assert_eq!(*shared_data.lock().unwrap(), 420);
 /// ```
 ///
-/// ... not really what we would do, but still not optimal either way.
+/// ... not really what we would do (really only minor style preferences, nothing
+/// actually relating to function), but still not optimal either way.
 ///
-/// In our short(...ish?) time writing rust code, I've already noticed I use
-/// this pattern a lot when dealing with shared state across threads. There are
-/// likely patterns that we don't know about (...or do, but haven't thought about
-/// at time of writing this documentation :p), and also maybe not always specifically
-/// `Arc<Mutex<Data>>`. Needing to write all that boilerplate for a very simple
-/// and straightforward operation, doesn't feel very ergonomic or elegant.
+/// In our short(...ish?) time writing rust code, I've already noticed I use this
+/// pattern a lot when dealing with shared state across threads. There are likely
+/// patterns that we don't know about, that would do something similar here (clone
+/// a value, then consume the clone, then access original). Or maybe we do know
+/// about them, but we haven't thought about it at time of writing this documentation
+/// :p. Needing to write all that boilerplate code for an otherwise very simple
+/// operation, doesn't feel very ergonomic or elegant, and quickly gets boring.
 ///
 /// This macro can help with that:
 ///
@@ -293,15 +299,15 @@
 /// assert_eq!(*shared_data.lock().unwrap(), 420);
 /// ```
 ///
-/// In my opinion, a bit less boilerplate, and a bit nicer.
+/// It cut out most of the boilerplate, and just feels a lot nicer to use.
 ///
-/// The syntax of the macro is, first a list of the variables that should have a
-/// cloned version available, followed by keyword `in`, then any statements
-/// you would like to run. Essentially, you can think of the stuff after `in`
-/// as just a regular block. Those who know what [swift closures look like] may
-/// recognise this syntax :p
+/// The syntax of the macro is, first a (comma seperated) list of the variables
+/// that should have a cloned version available, followed by keyword `in`, then
+/// any statements you would like to run. Essentially, you can think of the stuff
+/// after `in` as just a regular block. Those who know what [swift closures] look
+/// like may recognise this syntax hehe
 ///
-/// [swift closures look like]: https://docs.swift.org/swift-book/documentation/the-swift-programming-language/closures#Closure-Expression-Syntax
+/// [swift closures]: https://docs.swift.org/swift-book/documentation/the-swift-programming-language/closures#Closure-Expression-Syntax
 ///
 /// You can also bind the cloned values mutably, as well as return values out
 /// of the macro:
@@ -311,6 +317,8 @@
 /// let string = String::new();
 ///
 /// let modified_string = with_cloned! { mut string in
+///    //                                ^^^
+///
 ///    // do whatever
 ///    string.push_str("uwu");
 ///
@@ -326,8 +334,8 @@
 /// ```
 ///
 /// Ideally you could bind variables mutably or not on a per variable basis,
-/// but I can't seem to find a way to do so, unfortunately >< so it's all or
-/// nothing for now.
+/// but unfortunately, I can't seem to find a way to do so elegantly >~< so it's
+/// all or nothing for now.
 ///
 /// Random, but the below code snippets are equivalent:
 ///
@@ -335,8 +343,8 @@
 /// # use wiwi::with_cloned::with_cloned;
 /// # let value = String::new();
 /// let cloned1 = value.clone();
-/// // clones it for the inner code, but the inner code just returns it
-/// // ... so it's just a clone
+/// // macro clones it for the inner code, but the inner code
+/// // just returns it... so it is just a clone
 /// let cloned2 = with_cloned! { value in value };
 ///
 /// assert_eq!(value, cloned1);
@@ -345,7 +353,7 @@
 #[macro_export]
 macro_rules! with_cloned {
 	($($stuff:tt)*) => {
-		// hide potential distracting implementation detail in docs
+		// hide potential distracting implementation details in docs
 		$crate::with_cloned::_with_cloned_impl! { $($stuff)* }
 	}
 }
diff --git a/wiwi/index.html b/wiwi/index.html
index a1833fc5d..30fbe7c3f 100644
--- a/wiwi/index.html
+++ b/wiwi/index.html
@@ -75,7 +75,7 @@ 
ba80bae6.

+
These docs have been built from commit 1bd6b79f.

 
  1. Based on the benchmark available in this repo: wiwi is about 21.5x faster in encode, and 7.5x faster in decode. I want better benchmarks though. For now the hex crate also provides more flexibility, whereas wiwi::hex just exposes encode_hex, encode_upper_hex, and decode_hex functions.
  ↩
  2. Based on the benchmark available in this repo: wiwi is about 1.4x faster in encode, and 2.2x faster in decode. I want better benchmarks though. There is no functionality that the z85 crate provides, that we don’t also provide (encode_z85 and decode_z85 functions). ↩
Modules§