-
Notifications
You must be signed in to change notification settings - Fork 19
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
ACP: char::MIN
#252
Comments
SGTM |
I'm wondering where this would be used? Are there any more concrete examples? I get the point about rounding out the API but I don't think that's enough justification in itself. And all the places where maybe I guess macro use would be the strongest argument but it's not really an integer so it doesn't really make sense to me to have it in a macro with integer types. Maybe there is a real world example of where this would be useful? |
I'd probably use it here: https://github.com/rust-lang/regex/blob/a1910244f873e003efbe6e80ad9302c8ea949430/regex-syntax/src/unicode.rs#L708 I suspect there isn't really a case where |
You're not even using |
Or maybe that's an argument for having an ascii min too. |
Because it's IMO weird to write |
Ah I see, so you'd also want something like |
Just earlier I was manually implementing a trait for |
I guess "other integer types" is what I'm not getting. To my mind |
True, but there are many traits that you would implement for integers that you might implement for Sure, it's one special case, but it's still not clear it's worth putting your foot down and not having a |
Right but that's why I was asking for examples of where people would actually use it. Also note that char has a hole in the middle so min and max don't adequately describe its bounds. |
Process note: I think you just need sign off from one libs-api member (me in this case) to move forward with creating a PR and a tracking issue. My understanding is that debate carries on there as opposed to here. (I'm happy to corrected on process. I just wanted to throw this out there as my understanding at present.) |
That is, I agree that this is a plausible addition and that it's worth moving forward. But still fully expect to need consensus before stabilizing. |
I think that argument was already lost with the stabilization of https://doc.rust-lang.org/std/num/struct.NonZeroI32.html#associatedconstant.MIN in 1.70.
|
The current process is that you should add the tag "ACP-accepted" and close this issue. |
|
…tSushi Add char::MIN ACP: rust-lang/libs-team#252 Tracking issue: rust-lang#114298 r? `@rust-lang/libs-api`
Add char::MIN ACP: rust-lang/libs-team#252 Tracking issue: #114298 r? `@rust-lang/libs-api`
Add char::MIN ACP: rust-lang/libs-team#252 Tracking issue: #114298 r? `@rust-lang/libs-api`
Add char::MIN ACP: rust-lang/libs-team#252 Tracking issue: #114298 r? `@rust-lang/libs-api`
Proposal
Problem statement
Several standard primitive types offer
MIN
andMAX
constants, which have a variety of use cases across the ecosystem. Unfortunately,char
only offers aMAX
constant, and notMIN
.Motivating examples or use cases
While Rust doesn't offer generic traits for minimum/maximum bounds on types, the standard
MIN
andMAX
constants make implementing such functionality across a wide variety of types easy, since macros can simply expect<$t>::MIN
and<$t>::MAX
to exist. Unfortunately,char
only hasMAX
, notMIN
.One of the arguments for why
char::MAX
exists is that it's difficult to remember and easy to mess up. For example, the literal'\u{10FFFF}'
could easily be accidentally typed as\u{10FFF}
and would be easy to miss. However,char::MAX
is much harder to mistype without breaking, and is much clearer about its intent.Compare this to the minimum value
'\0'
which is substantially easier to remember and a lot clearer. However, keep in mind that unsigned integers have an even simpler minimum,0
, and these also haveMIN
constants.Solution sketch
Alternatives
The primary alternative is to simply not offer this constant, if the motivation doesn't justify it.
Links and related work
N/A
What happens now?
This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.
Possible responses
The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):
Second, if there's a concrete solution:
The text was updated successfully, but these errors were encountered: