Add impl From<&CompactDecimal> for PluralOperands

[sffc]

CC @sven-oly

[sffc]

Oof, the resolver was being too smart before, and now it's biting us. This is in tutorials-local CI:

error[E0283]: type annotations needed
  --> src/main.rs:16:24
   |
16 |     let result = rules.category_for(&3.into());
   |                        ^^^^^^^^^^^^    ---- type must be known at this point
   |                        |
   |                        cannot infer type of the type parameter `I` declared on the method `category_for`
   |
   = note: cannot satisfy `_: From<i32>`
   = note: required for `i32` to implement `Into<_>`

I thought adding impls was supposed to always be semver safe.

[sffc]

Adding @Manishearth as reviewer because of the resolver issue

[Manishearth]

I thought adding impls was supposed to always be semver safe.

No, it's actually expected: In general Rust does not consider "you will need to disambiguate" as a breaking change because otherwise you would never be able to add anything to your API. Adding From impls can have that effect.

[sffc]

I thought adding impls was supposed to always be semver safe.

No, it's actually expected: In general Rust does not consider "you will need to disambiguate" as a breaking change because otherwise you would never be able to add anything to your API. Adding From impls can have that effect.

ok so does this mean we can land this without a semver bump?

[Manishearth]

Yes

[Manishearth]

However we should use our judgement on how commonly we expect this breakage to cause actual problems.

[echeran]

LGTM

[sffc]

Yet Another Reason™ to not use Into bounds on function parameters.

(CC @zbraniecki @robertbastian who like to do this sometimes)

[Manishearth]

It's specifically the chaining of two Intos that's the problem here, I think. Ideally an API should never require that: there should be Into impls for integers as well.

It's rarely a real problem imo, and Into accepting functions are fine as long as you never need to feed them the output of a second into. Which you shouldn't need to.

[sffc]

Looking at the code, I'm surprised that the resolver looks at &3.into() as Into<PluralOperands> and decides to infer a FixedDecimal as the intermediate type when there is nothing suggesting that. Does it check every implementer of Into<PluralOperands> that's in scope and use it so long as it is unique? That seems really really brittle.

[Manishearth]

Yes, sometimes, it doesn't always work, I usually don't rely on it except in specific contexts.

[robertbastian]

Well don't call functions accepting Into<T> with x.into().

[Manishearth]

Yeah like I said going through Into twice is known brittle and nobody really does it,you should have a single bridging Into impl if possible

[sffc]

We all agree that clients shouldn't do this. My separate position is that functions should prefer accepting concrete types over things like Into or IntoIterator but we don't need to rehash that now. We should also consider adding the "bridging impls", but we can open a separate issue for that.

I guess the question for us at the moment is, given that we have had this docs example for quite some time, do we care that it breaks in 1.5?

[Manishearth]

IMO no, but I think we should invest in adding bridging impls.

[sffc]

Discussion: the call site is fragile and should be re-written anyway; it is only in a tutorial, not a docs test, which lowers the risk. This should be a Clippy lint. So this PR can proceed.

LGTM: @Manishearth @robertbastian @sffc

[sffc]

We already have impl From<{int}> for PluralOperands so I changed the tutorials to just pass the number straight in.

[sffc]

@robertbastian If you LGTM this PR, including the tutorial change, I will merge it.

[sffc]

Waiting on review from @eggrobin