Impossible to remove #![must_use] from a value

[alexchandel]

I want to write a macro wrapping something marked #![must_use] which doesn't spam the build output with "unused_must_use", but also doesn't destroy the result. I don't want to unwrap these values either, nor mark every single invocation with #![allow(unused_must_use)], nor allow unused_must_see for the entire program (because with this macro's one exception, it is useful): I simply want to strip this return value's compiler-spamming must_use.

This:

macro_rules! println_out(
    ($($arg:tt)*) => ( {let _ = writeln!(&mut ::std::io::stdout(), $($arg)* )} )
);

doesn't work because the result is unavailable if I need to check it, which I do on occasion.

Even this: fails to work:

macro_rules! println_err(
    ($($arg:tt)*) => ( {
        let _x = writeln!(&mut ::std::io::stderr(), $($arg)* );
        _x.is_ok();
        _x
    } )
);

because the final line can be unused in the calling context

stdout/stderr/write_ln! are used as examples here, but I need to do this generically with certain things that spam must_use.

This isn't an unsafety issue. I simply shouldn't have to be bound ubiquitously by the particular compiler-warning policy preached by a module's author. I may (and do) have valid cases where must_use is semantically wrong.

It should not be impossible to do this.

[durka]

Statement attributes will hopefully be stabilized soon, which should offer a nice way to do this (I say "should" because the current implementation doesn't work with lints).

Anyway, how about a simple wrapper type?

struct Unused<T>(T);

fn return_ok() -> Result<(), ()> {
    Ok(())
}

fn main() {
    Unused(return_ok()); // no warning
}

[Thiez]

Wrapping in a tuple works too: (return_ok(),)

[durka]

@Thiez though of course neither suggestion works if we ever make the lint smart enough to see through such things :)

[alexchandel]

I suppose using a wrapper or tuple at the invocation would be equivalent to calling is_ok(); or something every time, and the goal is to avoid putting dressings around the macro every invocation where I don't want compiler spam.

[alexchandel]

I don't think statement attributes work either, since even if they're on the macro, the problem is the invocation's warning happens outside the macro

[durka]

In my ideal world you would write

#[allow(unused_must_use)] println_err!("whatever");

or

#[allow(unused_must_use)] {
    println_err!("one");
    println_err!("two");
}

or have a macro generate such code. Outside of that, or the wrapper struct/tuple trick, I chalk this up to working as designed -- the whole point of #[must_use] is to remind you in case you forget to handle something. False positives are why it's a warning and not an error.

[alexchandel]

@durka

That's precisely what I don't want. And no macro can generate such code that also returns the value, because the value eventually escapes the attributed statement.

It's not "working as designed". This isn't an unsafety issue, or a lifetime issue, even syntactic. The Type's author may want to remind the user with compiler warnings, but if the user knows these warnings are incorrect (like for a particular semantic case of Result), they become spam. The fact that statement-based #[allow(unused_must_use)] is being added supports that it's a valid desire to selectively silence warnings.

I don't want to and shouldn't have to disable all must_use warnings, because that would defeat the purpose of it. I simply want to do it for invocations of this function. It's roughly analogous to this:

extern crate bob;

unsafe fn not_safe() -> u8 { bob::s::unsafe_function(0, "foo") }

fn guaranteed_to_always_be_safe() -> u8 { unsafe { bob::s::unsafe_function(1, "foo") } }

which is entirely permissible.

[Thiez]

@Thiez though of course neither suggestion works if we ever make the lint smart enough to see through such things :)

Why would we want that, though? I thought the lint was there to prevent accidents, not to enforce some strange variation on checked exceptions.

[bluss]

You'd can use the wrapper type in the macro, to keep the Result value silent but reachable on demand. (If you'd just want to silence each macro invocation manually, then the more popular let _ = .. and drop(..) solutions would be enough.)

[alexchandel]

@Thiez For the exact same reason unsafe { } blocks exist. Being there to prevent accidents doesn't mean you should tell users you know better than them in all cases. Type and memory safety is "there to prevent accidents" too, yet I can put an unsafe block inside a safe function if I, the user of another unsafe function, know that my usage is guaranteed to be safe. That's how the entire standard library and every single system binding works.

@bluss I considered a wrapper type, but accessing it with a .0 every time became silly. I ended up just calling .err() in the macro, which returns an Option that thankfully isn't tagged with the #![must_use]. This worked for most cases where I didn't care about the Ok variant.

[durka]

The point of #[must_use] is to introduce friction encouraging you to
use the value or explicitly decline to do so (like with the wrapper type).
I realize in this specific case that was annoying, though.

On Mon, Sep 26, 2016 at 6:24 PM, Alex [email protected] wrote:

@Thiez https://github.com/Thiez For the exact same reason unsafe { }
blocks exist. Being there to prevent accidents doesn't mean you should tell
users you know better than them in all cases. Type and memory safety is
"there to prevent accidents" too, yet I can put an unsafe block inside a
safe function if I, the user of another unsafe function, know that my usage
is guaranteed to be safe. That's how the entire standard library and every
single system binding works.

@bluss https://github.com/bluss I considered a wrapper type, but
accessing it with a .0 every time became silly. I ended up just calling
.err() in the macro, which returns an Option that thankfully isn't tagged
with the #![must_use]. This worked for most cases where I didn't care
about the Ok variant.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#36675 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC3n6X7XxTwkZ3tV7L7ypo7d8R5SC-bks5quEYqgaJpZM4KFP33
.

[steveklabnik]

Triage: no changes here.

Personal note: not sure if this is enough of a paint point to address. Not my call though.

[Dylan-DPC]

closing this as it feels like a niche request that hasn't got much attention in the last few years