Consider adding send-like method to MetricBuilder that ignores results

[56quarters]

Per #63, an attribute was added to the MetricBuilder to warn when it was unused. Thus, code like the following (incorrect, since the metric isn't sent) would generate a warning:

client.count_with_tags("some.key", 4)
    .with_tag("region", "us-east-1")
    .with_tag("host", "container-12345-abc");

However, the following (totally reasonable) code also generates a warning:

client.count_with_tags("some.key", 4)
    .with_tag("region", "us-east-1")
    .with_tag("host", "container-12345-abc")
    .send();

To avoid the warning, users need to do something with the Result from .send(), like...

client.count_with_tags("some.key", 4)
    .with_tag("region", "us-east-1")
    .with_tag("host", "container-12345-abc")
    .send()
    .ok();

To solve this, @robinst has suggested adding another method to MetricBuilder that sends the metric but does not return a result so that callers aren't forced to do something perfunctory with it.

Example (using the name send_quiet which I'm not at all attached to):

client.count_with_tags("some.key", 4)
    .with_tag("region", "us-east-1")
    .with_tag("host", "container-12345-abc")
    .send_quiet();

What are people's thoughts on this? Does adding another send-like method seem acceptable? If so, any thoughts on a name?

/cc @robinst @pjenvey

[robinst]

I was wondering if there's an example of a naming convention for that in the standard library. The only similar thing I found so far is _unchecked: https://doc.rust-lang.org/std/primitive.str.html?search=unchecked

But those methods are marked unsafe because the result might be bad, so it's not really the same thing.

Another option might be send_ignore()? Just playing around with names.

[56quarters]

send_ignore seems like a good choice to me.

[pjenvey]

I think every rust metrics lib I've seen returns a Result. I'm wondering if it's the wrong default in the first place w/ the nature of metrics, do most users ignore send results?

Maybe StatsdClient could have an error_handler (say defaulting to logging an error!) while changing send to not return a Result, w/ an alternative send API that does. Then at least the typical behavior isn't a complete ignore

[robinst]

Yeah that would also work for us. So you'd probably have send() -> () and try_send() -> Result methods?

[56quarters]

I like the idea of some sort of error handler such that errors aren't completely ignored. However, I'd rather not change the existing send method to send() -> () and instead add a new method that makes use of the error handler. Actually, I guess the breaking change might be fine since it's limited to the MetricBuilder. Thoughts?