Proposal: add range value type and range value conversions between different ranges.#3412
Proposal: add range value type and range value conversions between different ranges.#3412iddm wants to merge 3 commits intorust-lang:masterfrom
Conversation
ehuss
added
the
T-libs-api
|
It seems most likely this will eventually end up as pattern types in some form. See also the niches RFC as another way this was proposed. |
afaict that just addresses the existence of range types, but not conversion as is proposed in this RFC e.g. relative value preserving conversion from percent ( |
| type Target = V; | ||
|
|
||
| fn deref(&self) -> &Self::Target { | ||
| self.get() |
There was a problem hiding this comment.
Rust standard library types never implement Deref while having other methods as that could be confusing. get and range should be inherent methods without a self parameter.
|
It's unclear to me why this should be added to the standard library, instead of living in a third-party library. I would prefer ranged integers that can be statically checked and have no memory overhead, like |
| No known and reasonable drawbacks. | ||
|
|
||
| # Rationale and alternatives | ||
| [rationale-and-alternatives]: #rationale-and-alternatives |
There was a problem hiding this comment.
I think this is missing a section about why this needs to be in core instead of a crate, or why it's an important enough ecosystem primitive to be centralized into core instead of just letting people use it tomorrow in a crate.
|
As mentioned before, this could first live in a crate to show its readability without causing maintenance effort for libcore. I recommend you close this RFC and implement your idea as a standalone crate. If there is still a need for language or libcore support for it afterwards, the discussion can be restarted and possibly lead to an RFC again |
8 participants
I suggest having a strict type for a value of a range. This type can be converted into another value of another range. The solution to the problem of conversion from two integer ranges is always the same, as far as I know, and so it can easily be written once for everyone and used. I think such a small but helpful addition to Rust's standard library types, such as
std::ops::Rangeandstd::ops::RangeInclusive, would enrich their interface and make the user code a little more stable by providing guarantees that specific values always lie within the range from which it was taken from.Rendered