This can be used to avoid awkward start..(end + 1) constructions, which will trigger the clippy::range_plus_one lint.
I added a single impl for InclusiveRange rather than a blanket impl<T: RangeBounds> From<T> for SourceSpan for two reasons. The first is that the blanket impl would be a breaking change (because dependent crates may currently define a type T: RangeBounds and also have impl From<T> for SourceSpan). The second is that this would allow one-sided ranges (..x, x..). In order to support bounded-below ranges, we would need to change SourceSpan so that length may depend on the the specific SourceCode instance. That seems like an unlikely use case.
This can be used to avoid awkward
start..(end + 1)
constructions, which will trigger theclippy::range_plus_one
lint.I added a single impl for
InclusiveRange
rather than a blanketimpl<T: RangeBounds> From<T> for SourceSpan
for two reasons. The first is that the blanket impl would be a breaking change (because dependent crates may currently define a typeT: RangeBounds
and also haveimpl From<T> for SourceSpan
). The second is that this would allow one-sided ranges (..x
,x..
). In order to support bounded-below ranges, we would need to changeSourceSpan
so thatlength
may depend on the the specificSourceCode
instance. That seems like an unlikely use case.