scottmcm
scottmcm
> Not distinguishing between truncating and extending casts is a minor flaw, but likely better than attempting to distinguish these cases with separate traits. One thing I've been thinking here...
In particular, as the #2484 discussion shows, it's very hard to define a useful generic concept of "lossy" that isn't just "meh, it does something, good luck" -- because you...
I'd encourage you to have these discussions on IRLO or Zulip instead of here, as an issue tracker isn't a good place for the infinite list of possible future extensions...
@BGR360 Unfortunately the main blockers here are unknowns, not concrete-work-needing-to-be-done, so it's difficult to push forward. It's hard to ever confirm for sure that people *don't* need the trait split...
This absolutely is 👍 from me. (Thanks for the ping!) I'm a fan of it as described here where it's consistent with `(a + b) / 2`, like the discussion...
Actually, @Urgau , consider putting "and float" in the title & OP here. To me the "stabilize the unsigned variants" text wouldn't include floats, since they're obviously signed.
This makes me think of this conversation about `Display` adapters:
"Theoretically" reachable wouldn't be a workable rule. Just change the example to `if unsolved_math_problem(a, b) { hint::unreachable_unchecked() }` and it's clear: it's not reasonable to have the correctness of a...
It seems unfortunate if all the `track_caller` data in the binary needs to be bigger for everyone just because some people want to pass it to a random C API...
I think you're right and it violates ESI, as things that can make an iterator longer almost always do. If you start with `repeat_n(0, usize::MAX)` then add something to the...