Josh Stone
Josh Stone
I do think an environment variable is reasonable anyway -- there's precedent in other test options like `RUST_TEST_THREADS` and `RUST_TEST_NOCAPTURE`.
Wouldn't inline-const have the same diagnostic issue as OP's `const _: () = assert!(condition);`?
Sorry if I missed this in prior discussions, but `itertools` does have [`PeekingNext`](https://docs.rs/itertools/latest/itertools/trait.PeekingNext.html) and [`peeking_take_while`](https://docs.rs/itertools/latest/itertools/trait.Itertools.html#method.peeking_take_while).
I have yanked 0.2.154 with my `T-libs` crate access, but I don't think I have any permission in the repo to help get a new version out.
> > Regarding the open issues, as well as [cuviper/autocfg#43](https://github.com/cuviper/autocfg/pull/43) we are not able to detect using just autocfg if we have backtraces or nightly available. > > That's why...
In principle I think it would be fine to have `Target: ?Sized` on our `AsRef`, and on `AsMut` too. My only hesitation is whether this constitutes a breaking change to...
Your example works with concrete types though: ```rust impl AsRef for Either { fn as_ref(&self) -> &Unsized { match self { Either::Left(x) => x.as_ref(), Either::Right(x) => x.as_ref(), } } }...
I think we could still implement `AsRef` and `AsRef` though.
Sure, I've added the label.
Renaming it would be a breaking change, but we could add "std" as an alternate. I think the only time "use_std" would even be mentioned normally is for another crate...