You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
RangeInclusive has pub(crate) fields. This could be pub. #67371
I'm currently writing a library that generalizes all ranges and adds a "range set". Core/Std compatibility is a must and I want to make the crate "feel" as if it would already be part of them. This, of course, requires From implementations for all range types for my GenericRange<T>.
(note: this requires PartialOrd, because upon converting I assert, that start <= end to optimize other code that depends on this requirement)
The problem I'm facing now is that I want to keep clones at a minimum, but RangeInclusive<T> forces me to commit this atrocity:
impl<T>From<RangeInclusive<T>>forGenericRange<T>whereT:Clone + PartialOrd,{/// This requires `Clone` because for some reason the internal fields of `RangeInclusive` are/// only `pub(crate)` even though they could be `pub` and so we're forced to use the results of/// `RangeBounds`, which only return borrowed values.fnfrom(range:RangeInclusive<T>) -> Self{Self::closed(range.start().clone(), range.end().clone())}}
As mentioned in the doc comment and in the title of this issue, RangeInclusive<T> has pub(crate) fields, which prohibits other users, like me, to correctly take the fields without copying.
The crate is forbid(unsafe_code) and #![no_std] and I have thus no other way to implement From other than cloning the RangeBounds trait results.
If there is a reason for this I'm sorry for opening an issue - but I don't see one.
@memoryruins Thank you so much. That is exactly what I wanted. I'm so sorry I did not see this.
If this issue is not relevant anymore, I'd close it, but I'm not sure this issue will not come up again in the future by someone else. It just looks inconsistent and a comment or an indicator as to why it is not fully public should be added.
Activity
memoryruins commentedon Dec 18, 2019
It is certainly different from other ranges. #49022 links to some reasons and their respective PRs.
Notably, it mentions the
RangeInclusive::into_innermethod, which may be what you want here.https://doc.rust-lang.org/core/ops/struct.RangeInclusive.html#method.into_inner
Byter09 commentedon Dec 18, 2019
@memoryruins Thank you so much. That is exactly what I wanted. I'm so sorry I did not see this.
If this issue is not relevant anymore, I'd close it, but I'm not sure this issue will not come up again in the future by someone else. It just looks inconsistent and a comment or an indicator as to why it is not fully public should be added.
Rollup merge of rust-lang#67490 - Mark-Simulacrum:i-67371, r=Dylan-DPC