Peter Jaszkowiak

Indeed, the sketch solution doesn't resolve the `rand` case because those other types don't implement `Step`. A more general solution would be something like ```rust struct BoundIE { Included(T), Excluded(T),...

`ExactSizeIterator` is not implemented for several integer ranges, including `Range`.

I think many cases that would be helped by something like this probably just take an argument of `Range` (or `RangeInclusive`) directly, rather than accepting both. Some examples: - [`wgpu::util::RenderEncoder::draw*`](https://docs.rs/wgpu/latest/wgpu/util/trait.RenderEncoder.html#tymethod.draw)...

> std should add a default method into `RangeBounds` Unfortunately, this may not be possible because of existing impls like this one: ```rust impl RangeBounds for Range { ... }...

> the user API generalize to accept `RangeBounds` People find `RangeBounds` annoying to use. This ACP grew out of discussion about how to improve `RangeBounds` or otherwise make dealing with...

> Going back to my original use-case of `random_uniform` there I don't want a two-sided range, I want all possible ranges to work. Why shouldn't they? Conventionally `a..` means "a...

Another solution for the `into_bounds` problem that doesn't require an associated type, uses a new trait instead and guarantees move-only ```rust pub trait RangeIntoBounds { fn into_bounds(self) -> (Bound, Bound);...

Actually I think the associated type solution you propose would be a breaking change - `RangeBounds` is not a sealed trait. Even just adding a non-default method would be breaking.

You could use `Error::source`

What implements `Pattern`?