Change:
/// # Examples /// /// ``` <del> /// #![feature(nonzero_min_max)] /// </del> #[doc = concat!("# use std::num::", stringify!($Ty), ";")] #[doc = concat!("assert_eq!(", stringify!($Ty), "::MIN.get(), ", stringify!($Int), "::MIN);")] /// ``` <del> #[unstable(feature = "nonzero_min_max", issue = "89065")] </del> <ins> #[stable(feature = "nonzero_min_max", since = "CURRENT_RUSTC_VERSION")] </ins> pub const MIN: Self = Self::new(<$Int>::MIN).unwrap(); /// The largest value that can be represented by this non-zero

Discussion:
Currently, there is no way to obtain a value without introducing unsafe codes or calls, providing these constants can make it easier to use these types. For example: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this sounds like a good feature, and I would like to claim it for a first contribution.
claim
Not that I mind the addition of these constants in general, but your motivating example is a bit unfortunate in that it's a slightly obfuscated . It would be better served by: Yes, that does contain an , but it's provably unreachable and really the right tool for the job here. (Slightly better codegen too )
There are projects that forbid the usage of with Clippy. Using will require explicit attribute and maybe proper comment, which seems a little too much.
This might just be my head being in a more Ada space, but not having immediate access to the MIN and MAX for a given scalar type feels wrong to me. Obviously with a little forethought you can come up with a totally safe unwrap, but when you're doing something simple like initializing values for a comparison algorithm, it seems like it might be a bit better if you can use a constant which took care of that thinking about safety for you.
Thank you. This: is a good motivating example if you ask me. Sounds like these projects blanket forbid as a very coarse heuristic for the behavior they actually want to disallow. If this unwanted behavior is "there is an input that causes the program to panic (ignoring OOM)", you could teach Clippy to allow in const contexts. That way you get a compilation error if the panic path ever fires. The example you provided would then look like: Of course that currently requires nightly features and not sure how hard it would be to improve Clippy. Hopefully that will become viable for stable projects soon.
Some interrelated thoughts on the stated problems this is trying to solve: are a little weird, because in all other integer cases, all integers between MIN and MAX exist, but in the case of nonzero signed integers, there's also a hole in the middle. This seems an oddity worth thinking about and possibly documenting.

I also notice that the code example at the beginning of this thread cannot be written using these constants for because while is 1, is not. Also the code would be clearer in both cases if the value was named rather than . This suggests to me that possibly there should be a constant for NonZero types, or at least the signed ones. If there were to be , then the question of why not , , etc. comes up. The plausible response to adding any of them is "it's all moot once const panics are stable", but is still a long and tedious bit of code to write whenever you want a number literal. It would be nice if there was a specific or general way to improve such fallible-but-only-at-compile-time code. (I have some thoughts on this but they're further off-topic for this issue.) (None of this is intended to argue that and shouldn't be .)
I like the points made. I would concur that ONE as a constant might be useful, but should not be instead of a MIN, even for the signed integers. I think having the lowest possible value clearly demarcated as such has value. (It would be kinda nice to have a fast way of making number literals of this type. I think that would probably help with adoption. Feel free to tag me if you open an issue!)
Agreed. Not sure I follow. The code example at the beginning used and not . Yes, it does happen to add 1 - which incidentally also happens to be the value of - so you technically could implement the given example as: Luckily, I haven't seen anybody propose such a gross abuse of the constant. Yes, getting a literal is currently overly clunky and should be made easier and quicker. No doubt about that, but adding otherwise meaningless constants (be it or or ) isn't a good solution. Not sure how solutions could look that that are both ergonomic and feasible, but that's indeed going too far off-topic. If you end up writing down your thoughts on that, kindly cc me.
This is now available on nightly ().
Excellent, glad these have landed. Am discussing having these MIN/MAX available from traits:
Is there anything blocking the stabilization of this feature?
I guess this feature is simple and mature enough for stable toolchains. Are you willing to create a stabilization report?

fcp merge For the unsigned nonzero integers: For the signed nonzero integers:
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.