Josh Stone

Or, we could (secretly) promote those types to `core::ffi` / `alloc::ffi`, and the coherence problems will disappear.

You can make them `#[doc(hidden)]` too. FWIW, I would move as little as you can get away with, keeping most of the impls in std if possible. But I guess...

If this is for a type that you control, you can certain add such a method directly. The `num` traits are mostly for generics where you *don't* know or control...

You don't need to explicitly `map_err` at all, because the `?` operator can use this `impl From`: https://doc.rust-lang.org/std/boxed/struct.Box.html#impl-From%3CE%3E-for-Box%3Cdyn+Error%3E https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=91f94c462e49d0e463a0da09e340bad1

That rust-by-example could be written: ```rust fn double_first(vec: Vec) -> Result { Ok(vec.first() .ok_or(EmptyVec)? .parse::()? * 2) } ``` Edit: actually, they address this on the next page of the...

Rust as a language doesn't have `const trait` implementations yet, so we don't have any way to make stuff like operator `+` const. Most of the inherent methods of `Complex`...

For simple stuff like `Add`, at least it's not too bad to do it manually: ```rust const X: Complex32 = Complex32::new(1., 0.); const Y: Complex32 = Complex32::new(0., 1.); const Z:...

> e.g. even something simple like `const fn i()` would need const `Zero` and `One`. We do have some associated consts now, since #125! And rust-num/num-bigint#307 could even let those...

I think [`either_into`](https://docs.rs/either/latest/either/enum.Either.html#method.either_into) broadly meets this need -- your example can write `.map(Either::either_into::)`, or drive the type inference for `C` elsewhere like `.map(Either::either_into).for_each(|c: C| ...)`. It's a little wordy, perhaps,...

I don't know that I care to deal with a CLA for such a small change. I welcome anyone else to recreate this, which should be trivial even without looking...