Crates.io | tap |
lib.rs | tap |
version | 1.0.1 |
source | src |
created_at | 2017-06-24 22:48:02.47159 |
updated_at | 2021-02-13 02:43:25.525644 |
description | Generic extensions for tapping values in Rust |
homepage | https://github.com/myrrlyn/tap |
repository | https://github.com/myrrlyn/tap |
max_upload_size | |
id | 20530 |
size | 39,343 |
This crate provides extension methods on all types that allow transparent, temporary, inspection/mutation (tapping), transformation (piping), or type conversion. These methods make it convenient for you to insert debugging or modification points into an expression without requiring you to change any other portions of your code.
You can tap inside a method-chain expression for logging without requiring a rebind. For instance, you may write a complex expression without any intermediate debugging steps, and only later decide that you want them. Ordinarily, this transform would look like this:
extern crate reqwest;
extern crate tracing;
// old
let body = reqwest::blocking::get("https://example.com")?
.text()?;
tracing::debug!("Response contents: {}", body);
// new, with debugging
let resp = reqwest::blocking::get("https://example.com")?;
tracing::debug!("Response status: {}", resp.status());
let body = resp.text()?;
tracing::debug!("Response contents: {}", body);
while with tapping, you can plug the logging statement directly into the overall expression, without making any other changes:
extern crate reqwest;
extern crate tracing;
let body = reqwest::blocking::get("https://example.com")?
// The only change is the insertion of this line
.tap(|resp| tracing::debug!("Response status: {}", resp.status()))
.text()?;
tracing::debug!("Response contents: {}", body);
Some APIs are written to require mutable borrows, rather than value-to-value transformations, which can require temporary rebinding in order to create mutability in an otherwise-immutable context. For example, collecting data into a vector, sorting the vector, and then freezing it, might look like this:
let mut collection = stream().collect::<Vec<_>>();
collection.sort();
// potential error site: inserting other mutations here
let collection = collection; // now immutable
But with a mutable tap, you can avoid the duplicate binding and guard against future errors due to the presence of a mutable binding:
let collection = stream.collect::<Vec<_>>()
.tap_mut(|v| v.sort());
The .tap_mut()
and related methods provide a mutable borrow to their argument,
and allow the final binding site to choose their own level of mutability without
exposing the intermediate permission.
In addition to transparent inspection or modification points, you may also wish
to use suffix calls for subsequent operations. For example, the standard library
offers the free function fs::read
to convert Path
-like objects into
Vec<u8>
of their filesystem contents. Ordinarily, free functions require use
as:
use std::fs;
let mut path = get_base_path();
path.push("logs");
path.push(&format!("{}.log", today()));
let contents = fs::read(path)?;
whereäs use of tapping (for path modification) and piping (for fs::read
) could
be expressed like this:
use std::fs;
let contents = get_base_path()
.tap_mut(|p| p.push("logs"))
.tap_mut(|p| p.push(&format!("{}.log", today())))
.pipe(fs::read)?;
As a clearer example, consider the syntax required to apply multiple free
funtions without let
-bindings looks like this:
let val = last(
third(
second(
first(original_value),
another_arg,
)
),
another_arg,
);
which requires reading the expression in alternating, inside-out, order, to understand the full sequence of evaluation. With suffix calls, even free functions can be written in a point-free style that maintains a clear temporal and syntactic order:
let val = original_value
.pipe(first)
.pipe(|v| second(v, another_arg))
.pipe(third)
.pipe(|v| last(v, another_arg));
As piping is an ordinary method, not a syntax transformation, it still requires that you write function-call expressions when using a function with multiple arguments in the pipeline.
The conv
module is the simplest: it provides two traits, Conv
and TryConv
,
which are sibling traits to Into<T>
and TryInto<T>
. Their methods,
Conv::conv::<T>
and TryConv::try_conv::<T>
, call the corresponding
trait implementation, and allow you to use .into()
/.try_into()
in
non-terminal method calls of an expression.
let bytes = "hello".into().into_bytes();
does not compile, because Rust cannot decide the type of "hello".into()
.
Instead of rewriting the expression to use an intermediate let
binding, you
can write it as
let bytes = "hello".conv::<String>().into_bytes();
The Tap
and Pipe
traits both provide a large number of methods, which use
different parts of the Rust language’s facilities for well-typed value access.
Rather than repeat the API documentation here, you should view the module items
in the documentation.
As a summary, these traits provide methods that, upon receipt of a value,
AsRef
or AsMut
implementationBorrow
or BorrowMut
implementationDeref
or DerefMut
implementationbefore executing their effect argument.
In addition, each Tap
method .tap_x
has a sibling method .tap_x_dbg
that
performs the same work, but only in debug builds; in release builds, the method
call is stripped. This allows you to leave debugging taps in your source code,
without affecting your project’s performance in true usage.
Lastly, the tap
module also has traits TapOptional
and TapFallible
which
run taps on the variants of Option
and Result
enums, respectively, and do
nothing when the variant does not match the method name. TapOptional::tap_some
has no effect when called on a None
, etc.