Should tap allow the closure to return an ignorable value? #5

hzqd · 2022-01-10T05:47:12Z

I code this:

use std::io::stdin;
String::new().tap_mut(|s| stdin().read_line(s).unwrap())

Getting error message:

xx |     String::new().tap_mut(|s| stdin().read_line(s).unwrap())
   |                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `()`, found `usize`

It can be solved by adding brace and semicolon to the closure, but that doesn't seem ergonomic enough.

Do you think tap should allow the closure to return an ignorable value?

The text was updated successfully, but these errors were encountered:

tgnottingham · 2022-05-16T21:55:46Z

I don't think it should, because it introduces a new class of potential bugs. The current design prevents the user from falling into the trap of thinking that tap returns the value that the closure returns.

Here's a contrived example where the user might believe that this would print "HELLO HELLO", but it would only print "HELLO".

use tap::prelude::*;

fn echoed(s: &str) -> String {
    s.to_string() + " " + s
}

fn main() {
    let echo = "hello".to_ascii_uppercase().tap(|s| echoed(s));
    println!("{echo}");
}

hzqd mentioned this issue Jan 10, 2022

Make the tap closure return an ignorable value #6

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Should tap allow the closure to return an ignorable value? #5

Should tap allow the closure to return an ignorable value? #5

Uh oh!

Should tap allow the closure to return an ignorable value? #5

Should tap allow the closure to return an ignorable value? #5

Comments

Uh oh!