Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: add range value type and range value conversions between different ranges. #3412

Closed
wants to merge 3 commits into from

Conversation

iddm
Copy link

@iddm iddm commented Apr 10, 2023

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::Range and std::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

@ehuss ehuss added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label Apr 10, 2023
@clarfonthey
Copy link
Contributor

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.

@programmerjake
Copy link
Member

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 (0..=100) to ppm (0..=1000000) or fp fraction (0.0..=1.0)

type Target = V;

fn deref(&self) -> &Self::Target {
self.get()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I will change.

@Aloso
Copy link

Aloso commented Apr 13, 2023

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 int<5..13>.

No known and reasonable drawbacks.

# Rationale and alternatives
[rationale-and-alternatives]: #rationale-and-alternatives
Copy link
Member

@scottmcm scottmcm May 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@oli-obk
Copy link
Contributor

oli-obk commented May 16, 2023

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

@iddm iddm closed this May 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants