Add AsPrimitive trait for generic casting with as

[Enet4]

This is my personal attempt at #7. It is fairly similar to what can be found in asprim, although implemented from scratch. Please let me know of what you think. Could it use more tests? Should I also leave a safety notice that some conversions with as are currently UB (rust-lang/rust#10184)?

[cuviper]

Ah, you've made this a little more powerful than asprim by using a type parameter, so implementations don't have to support all the same types. Neat!

@bluss -- as the author of asprim, I'd like to know what you think of this simplified AsPrimitive.

The tests are fine -- given that Rust doesn't do any implicit conversions here, I think this is one of those "if it compiles, it works" situations. There's no wiggle room for a logic bug here. (Murphy's law -- someone will probably point out how this could have a bug...)

I do think the UB should be mentioned and linked. Another one is rust-lang/rust#15536.

[cuviper]

Interesting that you include char -- I think we could justify bool to integers as well. Pointers can also use as, but I think it's fair to leave that outside the realm of num.

[Enet4]

I agree with the conversion from bool to integer types, just punched them in.

I might also add that this implementation has this tiny catch (does asprim have this as well?):

let pi: f64 = 3.1415926535897932384626433832795;
if pi.as_() == 3_u16 {
    println!("All good");
}

The compiler cannot resolve to AsPrimitive<u16> here, because there could be another AsPrimitive<T> where T: PartialEq<u16>. Making it explicit or performing the comparison the other way around works.

let pi: f64 = 3.1415926535897932384626433832795;
if 3_u16 == pi.as_() {
    println!("All good");
}

[Enet4]

Just a heads-up: I forgot to add a Safety section the other day, so I added it now. What do you think?

I configured the new doctests in the description to be ignored, although they compile fine. I'm not sure whether it's important to compile some UB-inducing code.

[bluss]

Lgtm. Give it a thought -- is this an interface that others can implement, should they, or should they not? Documenting that rule would be good. Most probable rule is that the impl is only "admitted" if there is an corresponding as cast.

[bluss]

As always, the best method for implementation isn't necessarily the best interface for calling. The trait Into incidentally also has this problem. What I think of as the best interface for calling is something that admits foo.as_::<NewType>(). AsPrim has that, incidentally, but it has the other drawbacks of that.

[Enet4]

Thanks for the feedback, @bluss.

Give it a thought -- is this an interface that others can implement, should they, or should they not? Documenting that rule would be good. Most probable rule is that the impl is only "admitted" if there is an corresponding as cast.

Agreed. It's hard to imagine good use cases for external implementations, though. Would it be for primitive newtypes (say, struct Foo(u32))? I wonder if expressions such as (5.0).as_().into() can be resolved unambiguously.

What I think of as the best interface for calling is something that admits foo.as_::(). AsPrim has that, incidentally, but it has the other drawbacks of that.

Yep, I am aware of this issue. This sounds like a blue-red pill decision between having more possible conversion sources/targets (char and bool) or having a better user-facing API. Whichever is more appealing to the community, I'll make the necessary changes if need be.

On the other hand, given that asprim seems to be well maintained right now, choosing to keep this API here would give users the power to choose either one as they wish (or both, but that would be pointless and just terrible 🙃).

[cuviper]

The noisy_float crate comes to mind as an example that might implement this.

[cuviper]

I think I'm ready to merge -- are you happy with those final questions of the interface as-is?

[Enet4]

My apologies, I sort of forgot this PR. In the following hours I could add a statement to the documentation mentioning that external types may implement AsPrimitive when they behave like a primitive numeric type, and the intended conversion does not fail (although it can result in precision loss or truncation). This should enable types such as those found in noisy_float to implement the trait without looking unintuitive.

Update: It's in.

[cuviper]

Looks good, thanks!

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push