Josh Stone

It is already using that algorithm, but since it's written for generic `T: Integer`, it's keeping those iterative values as `BigUint` in your case, rather than local `n: usize, k:...

Sure, we could call this out in documentation.

If you want me to consider the clippy fixes now, please keep that in a distinct PR. Doing too much in one PR is a pretty sure way to make...

Adding `FloatCore` is a breaking change, at least -- that was considered in #295, but didn't seem important. Thematically though, I would expect them to be called `total_min` and `total_max`,...

I see -- I wasn't aware of those unstable methods. However, the [tracking issue](https://github.com/rust-lang/rust/issues/91079) still has a number of unresolved questions, and I'd rather wait to see that stabilized before...

Maybe something like `Ident::try_new` (and `_raw`) would be better?

You would still have a problem if the function changed from `Result` to a real error you should handle. There are also many other `#[must_use]` types and functions that should...

`#[fundamental]` changes what coherence considers covered, which can break downstream code, e.g.: ```rust pub struct Foo(pub [u8]); impl AsRef for std::sync::Arc { fn as_ref(&self) -> &Foo { todo!() } }...

Actually, adding `#[fundamental]` doesn't even get past `alloc` itself: ``` error[E0119]: conflicting implementations of trait `TryFrom` for type `Rc` --> alloc/src/rc.rs:2745:1 | 2745 | impl TryFrom for Rc { |...

Not in `alloc`, because that has no access to the `OsStr` type. It might be hackable in `std` using `#[rustc_allow_incoherent_impl]`, but "the only currently supported targets are inherent methods" --...