False positive for inherent_to_string_shadow_display?

[huxi]

I think I found a false positive or at least questionable case of inherent_to_string_shadow_display rule triggering.

The place this rule is (or rather "was", since I disabled it) triggered:
https://github.com/huxi/rusty_ulid/blob/72ac82736311981d12c339b78756049f48406179/src/lib.rs#L557

The place where the method in question is used to actually implement Display:
https://github.com/huxi/rusty_ulid/blob/72ac82736311981d12c339b78756049f48406179/src/lib.rs#L571

This boils down to a situation where a type has an efficient implementation of fn to_string(&self) -> String that is used to implement fn fmt(&self, f: &mut fmt::Formatter<'_>) -> Result<(), fmt::Error> of fmt::Display.

I think this case (method is used to implement trait) shouldn't trigger the rule.

[flip1995]

You should just write

impl fmt::Display for Ulid {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> Result<(), fmt::Error> {
        let mut string = String::with_capacity(26);

        crockford::append_crockford_u64_tuple(self.value, &mut string);

        write!(f, "{}", string)
    }
}

and remove the to_string method.

This will give you a to_string method, that calls fmt to produce the string. It's pretty much the same implementation as yours, but the other way around.
https://doc.rust-lang.org/src/alloc/string.rs.html#2132-2142

Or does something prevent an implementation like this?

[huxi]

I thought the way I'm doing it would be slightly more efficient, i.e. only one String::with_capacity(26) with exact required size already known vs. that same allocation plus everything the default implementation of to_stringdoes.

[flip1995]

I thought the way I'm doing it would be slightly more efficient

I doubt that. One great thing about Rust are Zero Cost Abstractions; the way it's implemented by the compiler should be at least as fast as your implementation.

What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better.

I expect that the default implementation of to_string will be optimized out by the compiler anyway.

---

Just tested it with godbolt: https://rust.godbolt.org/z/0Ynb4g

The version with just the Display implementation produces less Code than the version with the to_string implementation.

---

So yeah: Just trust the Rust compiler, he/she/it just wants what's best for you ❤️ 😄

[huxi]

@flip1995 There are some benchmarks in my repository.

With my current manual implementation:

generate_ulid_string    time:   [197.75 ns 199.60 ns 201.66 ns]
Found 8 outliers among 100 measurements (8.00%)
  8 (8.00%) high mild

Using the default implementation of Display instead:

generate_ulid_string    time:   [338.23 ns 340.84 ns 343.38 ns]
                        change: [+68.709% +70.540% +72.419%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 3 outliers among 100 measurements (3.00%)
  3 (3.00%) high mild

[flip1995]

Do you run these benchmarks in --release mode? Maybe you have multiple to_string calls spread throughout the code, which don't get optimized in debug mode. If you find the same behavior in --release mode feel free to reopen

[huxi]

I simply executed cargo bench with cargo 1.38.0-nightly (e853aa976 2019-08-09) which executes the criterion benchmarks after building them in optimized release mode.

Reverting the changes causes the performance to increase accordingly:

generate_ulid_string    time:   [193.82 ns 194.85 ns 195.95 ns]
                        change: [-42.510% -41.993% -41.431%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 3 outliers among 100 measurements (3.00%)
  3 (3.00%) high mild

Taking a look at the inherent_to_string_shadow_display description, it seems that the intent of this rule is mostly about preventing different output from to_string and fmt and I agree that this would indeed be quite bad.

But in my example this problematic behavior is impossible because fmt is actually using the to_string implementation, guaranteeing that output will definitely be identical.

I have no idea how prevalent this other-way-around pattern is but I think that it should not trigger the rule if it is detected.

The description of the rule also says "The less versatile inherent method will then shadow the implementation introduced by Display." but I don't see how the default implementation via Display is more "versatile" than the manual implementation.

@flip1995 I think I can't reopen the issue. I could only create a new one referencing this one.

[flip1995]

Fair enough. Could you test what happens if you implement the ToString trait instead of the to_string method, please. If this also works with the same performance, I would prefer this as a "this-is-how-you-should-do-it-instead"-suggestion. I think we even have a lint for "This method already exists in this trait".

I think I can't reopen the issue

Oh I thought the author can always do this. In that case I do it for you.