Abstracting type limits (numeric and not only).

[vityafx]

This RFC proposes to add a unified way of introducing type limits, for both numeric and non-numeric types (custom).

Rendered

[Centril]

Added a rendered link for you =)

[Centril]

I'm sympathetic to the core idea behind this RFC. Here are some hopefully helpful comments =)

[Centril]

I'm sympathetic to the core idea behind this RFC. Here are some hopefully helpful comments =)

[Centril]

What is the use case for Limits<A> for B where A != B ?

[vityafx]

1. A "shorthand" for inner type of strong types: struct Id(pub u64) and impl Limits<u64> for Id. But this is arguably since we made strong type exactly for hiding the inner type and we will violate the strong type's meaning by exposing its internal type in a trait.
2. Well, I thought I had a reason for this, but I don't remember it. Could you think any reason?

[Centril]

On 2. I'm afraid not =)

[vityafx]

So as I also don't remember why I did it so (what I was thinking about during writing), we may turn it into a simple trait then.

[Centril]

In all of your examples below, you've used constant which is known at compile time.
As the function is like () -> T, this means that an associated constant can be used instead as shown below.
Have you considered this design and if so, why did you discard it?

trait Limits<T> {
    const MIN_VALUE: T;
    const MAX_VALUE: T;
}

[Centril]

Also.. Why a combined trait instead of one trait for min and one for max?

[vityafx]

Nice! Don't know why I forgot we are able to do this in traits! This looks nice, but the question then: why do we have min_value() and max_value() methods for all primitive types for this?

[Centril]

My guess is that these inherent methods precede the stabilization of associated constants, but I could be wrong.

[mark-i-m]

@Centril I don't quite understand. Do you mean that before we can have a constant, we need a method? Or simply that the associated constants feature didn't exist when the methods were introduced?

[mark-i-m]

Also, I would prefer MAX and MIN so we can reuse std::*::MAX, etc...

[Centril]

If there is a use case for runtime-determined (non-const) max/min values, it is perhaps best if this RFC blocks on #2237. Then you can have opt-in const-ness.

[vityafx]

About combined trait: we may do even better: we may have Limits trait which just requires MinValue and MaxValue traits.

[vityafx]

About function vs constants. I prefer both the flexibility and simpliness. However, neither constants nor functions have both of them:

1. Constants are constant. They are written once and just used later. This is simple, but is not flexible: we can't write complex code for calculating it without magic.
2. Functions are not simple but flexible: you may write both constant value and complex logic there, but as a language entity it is more complex, that just constants. The also reason why functions in a trait are worse is that if you really just want to return a constant you still can't write const fn because it is unstable yet.

So, the question is open, I guess. If I am wrong anywhere, correct me please.

[brendanzab]

My guess is that these inherent methods precede the stabilization of associated constants, but I could be wrong.

min_value and max_value were always intended to be turned into constants, but they were added pre-1.0, long before associated constants were added! We used to have a Bounded trait, but they were rolled back after we simplified the numeric API for conservative reasons before stabilizing the standard library. I think it now lives in the num crate.

[Centril]

This feels a bit thin, expanding this section a bit would be helpful.

[vityafx]

Okay. :) I will expand it.

[Centril]

Please elaborate on why this has to be in the standard library and not in a separate crate.

[vityafx]

Because if we have it standardized, the standard library types should implement it as all of them already have it implicitly by providing min_value() and max_value() methods. One more reason is that such a trait is really not enough to be a separate crate.

Are these reasons enough?

[scottmcm]

Historically no, the same way there isn't a trait for wrapping_add, next_power_of_two, rotate_left, etc, all of which are implemented already on the core types without a trait.

[vityafx]

@scottmcm Do you think it should be in a separate crate? Could you tell why you think so please?

[scottmcm]

@vityafx Personally, I like traits for things, to be able to write stuff as generics instead of macros. But the standard library tends to be more conservative about adding traits, leaving that to the num crate and friends. So this RFC needs to address that.

[vityafx]

I think that moving this to the num crate and removing these static methods from the std's types will cause compilation failures for everyone who uses it.

[scottmcm]

Removing, sure, but you don't need to remove the std implementations to have them on a trait: http://rust-num.github.io/num/num_traits/bounds/trait.Bounded.html

[vityafx]

Yes, but why do we need the implementations for the standard types then in a separate crate? And also, we talked about requiring PartialOrd and not removing these methods will violate this rule.

[Centril]

The language in this section could be improved a bit =)

[vityafx]

Unfortunately I am not an english native speaker. Could you correct me please?

[Centril]

I'd write it as (with some slight semantic changes and clarifications and added Haskell as an example):

The motivation is simple: By providing the methods in a trait, user code is able to require with a bound X: Limit<Y> that X has certain limits of type Y, which enables generic reasoning and simplifies code.

Another motivation is that we already have inherent methods .max_value() and .min_value() on all primitive numeric types. Generalizing those methods as a trait simplifies the code and avoids duplication.

Looking at other languages, C++ provides std::numeric_limits, while Haskell provides the Bounded typeclass. This provides precedent that such a facility belongs in the standard library.

[Centril]

If you can show why the "generic version" is needed and what use cases are enabled by it, then we are closer to solving this question.

[Centril]

this function will succeed

Do you mean to say "this function will type check" or "this function will successfully compile" ?

[vityafx]

This function will successfully compile, thanks for this :)

[Centril]

typo: what has => that has.

[Centril]

Removing the type method is not required

Did you mean: Removing the inherent methods on the types is not required ?
An inherent method is one that has the form (including with &self, &mut self, type parameters, and where clauses):

impl MyType {
    fn inherent_method(self, arguments) -> return_type {..}
}

Removing those methods would not only not be required but would also break backwards compatibility if done.

[vityafx]

I meant removing const fn u64::min_value() -> u64 is not required because it works for me even so (I have implemented this trait and when I call Type::min_value which is a method of my trait it calls it instead of the static method of a type).

[Centril]

A simple reason: This is possible as a crate. The RFC should show why this needs to be in the standard library.

[vityafx]

Thanks, going to think how to write it there.

[Centril]

This should probably be <T = Self> if we allow a type parameter T there to make the use more ergonomic.
See std::cmp::PartialEq and (a lot of) friends for precedent.

[vityafx]

Good notice!

[Centril]

@Centril Thank you very much for your comments here. Should I answer here and when we come to a compromise reflect the result in the rfc itself or should I answer right there in the rfc file?

On-going discussion should mainly happen in comments on the PR itself rather than the file you're proposing we merge. To the extent possible, prefer line comments and replying to them as it is the closest we can get to threaded discussion, on GitHub, which tends to be more readable as it allows us to discuss a single issue at a given place rather than mixing all issues together. Whenever you feel that you've changes to make that elaborate, change design decisions, adds alternatives, and so on, just add additional commits.

[mark-i-m]

Can associated constants be used instead?

EDIT I mean this: https://doc.rust-lang.org/1.15.0/book/associated-constants.html

[mark-i-m]

Also, this RFC seems to be using the older format, rather than the newer format.

[Centril]

@mark-i-m Please continue discussion here regarding associated constants.

[vityafx]

@mark-i-m Heh, did not think the format could change somehow. Should I rewrite it using new template?

[mark-i-m]

@vityafx TBH, I don't know. I guess it would be nice if it's not too much trouble.

[scottmcm]

Can you clarify what the expected semantics of Limits are? Is it ∀x:T, T::MIN <= x && x <= T::MAX? If so, should it be Limits<T> : PartialOrd<T>?

[vityafx]

@scottmcm Awesome question. But it needs a small decomposition:

1. Are all of possible implementors of Limit trait must have different values for MIN and MAX ?
2. If so, should the type be comparable?
3. If so, should it be comparable via PartialOrd trait or maybe via custom user methods?

Now it is difficult for me to answer these questions. The possible drawbacks in my opinion are:

1. It is possible to have such types which may have equal limits (min and max). It is possible because I think it is very rough to say the opposite.
2. Requiring the type to be comparable is something extra we ask a user to do. I'd let the user decide what he wants to do. If it were impossible to use Limits without ordering, then I'd say we have to require ordering, but since it is not, I doubt we should.
3. Even then, it is a good practice to use PartialOrd and Ord and anything else. But what if the user
   decides to write his own ordering trait and methods - we will require a useless trait implementation, which probably, will be impossible to write (if the user ordering methods need some extra parameters).

What do others think?

[xfix]

This feature exists in Haskell as Bounded type class with minBound and maxBound functions. The documentation also says it's intentionally not Ord with a following explanation.

Ord is not a superclass of Bounded since types that are not totally ordered may also have upper and lower bounds.

[Centril]

∀T : PartialOrd<T> + Limits<T>. ∀x : T. T::MIN ≤ x ∧ x ≤ T::MAX does not hold since x may be unrelated to either T::MIN or T::MAX. Therefore, Limits<T> : PartialOrd<T> would have to be Limits : Ord, but then you would loose expressive power as @xfix shows.

---

Proof by counterexample:

fn main() {
    fn proof_partial_ord<T: PartialOrd>() {}
    proof_partial_ord::<f64>();

    assert_eq!(std::f64::MIN <= std::f64::NAN, false);
    assert_eq!(std::f64::NAN <= std::f64::MAX, false);
}

[xfix]

Haskell doesn't define Bounded for floating numbers either. It defines it for what looks like:

• Machine-size integers
• Enumerations (like boolean or Ordering)
• SIMD vector types
• Raw pointers
• Tuples of bounded types
• Monoids (not to be confused with monads) and semigroups of bounded types

[vityafx]

So, we end the ordering question with not requiring it, am I right?

[mark-i-m]

Or by getting everyone to stop using floating point...

[Centril]

@mark-i-m In any case PartialOrd is not enough if you add such invariants.

[scottmcm]

So, we end the ordering question with not requiring it, am I right?

I agree about not requiring Ord, but FWIW, wiki's definition of bounds is only over a partially-ordered set, so I still like PartialOrd.

Regardless whether there's a trait bound or not, the "what's the expected behaviour?" question still needs to be answered. Perhaps floating point just can't implement a general Bounded trait because of NAN, the same what that prevents it from implementing Ord, so it'll just have a f32::MIN that's not part of Bounded trait the same way it has a f32::min() that's not part of the Ord trait.

Edit: for clarity after an IRC discussion, I'm not proposing adding these properties to PartialOrd, but instead something like

trait Bounded<T = Self> : PartialOrd<T> {
    /// ∀x : Self, Self::MIN <= x
    const MIN: T;
    /// ∀x : Self, Self::MAX >= x
    const MAX: T;
}

Looking at other languages, C++ provides std::numeric_limits

Reminder just how many things are on numeric_limits: http://en.cppreference.com/w/cpp/types/numeric_limits#Member_constants. It argues more for separate Integer and Float traits, as it has specific things like is_signed and max_exponent.

[vityafx]

Okay, we stopped on requiring PartialOrd. I'll add this. But there is also a question which was not answered: should we used associated constants or trait methods? If methods, should they have a Self context? I can't exactly say what is better. For example:

1. Using trait methods are more subtle than just associated constants. Associated constants are constants, but min() can produce values based on some context (not only self but anything from the global namespace).
2. Constants can not be initialized via anything that is not known at compile time. So, you can not have associated constant which is a result of some function. This is a restriction. By accepting the associated constants we must fully agree that this restriction does not harm the usability.

[vityafx]

@scottmcm

Perhaps floating point just can't implement a general Bounded trait because of NAN, the same what that prevents it from implementing Ord, so it'll just have a f32::MIN that's not part of Bounded trait the same way it has a f32::min() that's not part of the Ord trait.

I'd do the same. I guess we can do nothing better than that.

[burdges]

I'd kinda imagine this'll go like const type parameters, meaning the deeper theory needs to be explored first, like ticki did with const-dependent types, to demonstrate that some limited feature set is both useful and has agreement in the wider programming language community.

In that vein, I'd suggest someone read up on, or even survey, related features like refinement types in languages designed for formal verification of production software, like F* (paper) and ProVerif. I donno if all their theory makes sense in a language with mutability, etc. but maybe enough does.

As for floats, I do not buy @Centril argument that Bounded : PartialOrd requires Bounded : Ord. Yes, if T: Bounded<f64> means T::MIN <= x && x < T::MAX, then std::f64::NAN is not in T, which sounds fine formally but likely creates implementation headaches. In fact, f64 is already both PartialOrd and naively bounded by std::f64::INFINITY and std::f64::NEG_INFINITY, except for std::f64::NAN. It manages this by relaxing the reflexivity requirement for a mathematical partial order, which creates issues mathematically but that's floats. If you similarly define T: Bounded<f64> to mean !(x < T::MIN) && !(x >= T::MAX) then everything works for std::f64::NAN, you do not require Ord, and std::f64::NAN is always present. You break std::f64::NEG_INFINITY with <, but adding more corner cases can fix it I guess.

Anyways, I think examining F*, ProVerif, etc. will provide a far better answer to the floats question than Haskell, like maybe nobody even included floats when doing formal verification, or maybe you need refinement types than can clearly express all the allowed special float values.

[brendanzab]

Yup. If there's one thing I learned in my explorations on numeric libraries, it's that Haskell really messed up on the Haskell 98 numeric type classes. So take what they do with a big grain of salt!

[scottmcm]

If you similarly define T: Bounded<f64> to mean !(x < T::MIN) && !(x >= T::MAX) then everything works for std::f64::NAN

Unfortunately, that loses uniqueness—that expression is also true if you set both MIN and MAX to NAN.

[mark-i-m]

@scottmcm This is technically not true since NaN != NaN...

[scottmcm]

@mark-i-m But the definition didn't mention anything about != 😁

[mark-i-m]

@scottmcm what I mean is that you can have MAX = NaN and MIN = NaN and still have uniqueness because MAX != MIN. This strikes me as absolutely ridiculous, but it is technically true :P

[scottmcm]

@mark-i-m Ah, sorry I misunderstood. I meant non-uniqueness in the sense that NAN and -INF are both valid values to satisfy the limits on MIN under that definition, so I consider it insufficient.

[fstirlitz]

Yes, minimal and maximal elements aren't unique in a general partial order, but floating-point types are just one example of that. (Ignoring here that floating-point values aren't technically partially ordered because ¬(NaN ≤ NaN).) The floating-point types simply have no greatest and smallest value, but both NaN and +∞ are maximal values, and both NaN and −∞ are minimal values.

How about creating newtypes which would be able to contain any floating-point value except NaN? I am preparing an RFC proposing a feature like that (I'm not sure when I'll be able to submit it, though). For such a type, implementing a type limit trait would be straightforward.

I'd also suggest splitting limits into two traits. Some orders may have one limit, but not the other. Consider the prefix order; in Rust terms, an ordering for &'_ [T] where a <= b means b.starts_with(a). This partial order has a smallest element &[] (and even a greatest-lower-bound operation, i.e. the longest common prefix), but no greatest element.

[vityafx]

A question for those who knows the rfc process better than me: is it really bad if it will be a breaking change? I mean, if we move those implementation to a trait and remove them from the types implementations, we will require the user code to add use Limits; line as we are using it.

Another way would be to deprecate using type's static methods.

[vityafx]

One more question: I'd agree with using associated constants if it were able to use methods/functions for their initialization. Now it is impossible and even const fn is unstable, so I'd suggest to use trait methods then.

[Centril]

@vityafx

is it really bad if it will be a breaking change?

Yes, but it depends on how extensive the breakage is, and that would have to be measured with a crater run... If the breakage isn't too extensive, then it can be done with an epoch.

I mean, if we move those implementation to a trait and remove them from the types implementations, we will require the user code to add use Limits; line as we are using it.

Not necessarily. If Limits is in the prelude, then you will not have to use Limits; (unless a user has done use Limits; for a trait from some other crate that does not do the same thing, but that is probably unlikely). However, there is a higher bar for adding things to the prelude.

Another way would be to deprecate using type's static methods.

That is probably a good idea.

[vityafx]

@Centril so what if we add it to a prelude and deprecate using of static methods? Sounds like the best option at this moment to me.

[Centril]

@vityafx

One more question: I'd agree with using associated constants if it were able to use methods/functions for their initialization. Now it is impossible and even const fn is unstable, so I'd suggest to use trait methods then.

I agree. You can get back the constness of the methods in Limits with const impl as discussed in RFC #2237 or with some other const polymorphism / effect system proposal. So I think that is the more flexible proposal.

@Centril so what if we add it to a prelude and deprecate using of static methods?

So I'd recommend taking a look at the other things that are in the prelude. In particular, the documentation states:

It's kept as small as possible, and is focused on things, particularly traits, which are used in almost every single Rust program.

Does Limits fall under that category? I'm skeptical.

[vityafx]

@Centril

Does Limits fall under that category? I'm skeptical.

Well, I agree.

I agree. You can get back the constness of the methods in Limits with const impl as discussed in RFC #2237 or with some other const polymorphism / effect system proposal. So I think that is the more flexible proposal.

Should I wait for the #2237 being merged before continuing?

[scottmcm]

MIRI is coming soon, so I think sticking to consts is better unless there's a persuasive situation in which a limit really can only be computed at runtime and the bound is important.

I mean, if we move those implementation to a trait and remove them from the types implementations, we will require the user code to add use Limits; line as we are using it.

There's no requirement to remove them from the types' implementations just because the trait exists. They shouldn't do different things, because that would be confusing, but the inherent method will take priority in resolution, so there's no need for a breaking change discussion here.

And there's no reason to remove a method from, say, f32 just because it has the same name as a trait method. There's still f32::min as an inherent method (on a type that's not Ord) even though there's also Ord::min as a trait method. The f32 has its definition for the cases that make it not Ord.

[vityafx]

@scottmcm what is "MIRI"? :)

[Centril]

@vityafx

Should I wait for the #2237 being merged before continuing?

I don't think that is necessary, and #2237 will probably not be merged in its current form, I'll have to rework it.. Whether or not Limits should use associated constants depends on whether you think there's any scenario where you'd want both the bound and a runtime computed bound. If there is, we should go with methods, because they can be made opt-in const after the fact.

@scottmcm what is "MIRI"? :)

https://github.com/solson/miri

[vityafx]

@Centril

Whether or not Limits should use associated constants depends on whether you think there's any scenario where you'd want both the bound and a runtime computed bound. If there is, we should go with methods, because they can be made opt-in const after the fact.

Totally agree with this and I told this a month ago here. So, I can't guarantee that someone would want the value to be evaluated at runtime. So I'd use the most generic solution which can be tuned to be computed both at compile time and runtime.

https://github.com/solson/miri

Could you tell how this can help? Don't quite understand..

[oli-obk]

So I'd use the most generic solution which can be tuned to be computed both at compile time and runtime.

Can you give an example with runtime limits, so we have something concrete to discuss?

Could you tell how this can help? Don't quite understand..

I think all that was meant by the miri-comment is that miri allows you to compute many things that were previously out of scope of const eval and needed to be done at runtime. It doesn't help for inherently runtime things.

[vityafx]

@oli-obk

Can you give an example with runtime limits, so we have something concrete to discuss?

The thing is I can't be responsible for each user. I am not a god. Even if I don't provide an example, I can't guarantee there is no case for that. Could you?

[eddyb]

I think the value of putting limits in types diminishes greatly when they're not const. That is, you should use your own abstraction if you have such usecases, and not limit (heh) everyone else with it.

[mark-i-m]

what is "MIRI"? :)

It's the new const evaluation system in rustc. It's been under construction for a while, but it's now making it into nightly: rust-lang/rust#46882

[oli-obk]

This RFC could live entirely in a crate, could it not? Or is there a use case where libstd could make use of it?

[vityafx]

I wanted to get rid of u64::max_value() methods and for other types, because it will duplicate the functionality. Getting rid of these types and making limits be a separate crate is a breaking change. Also, it is not clear for me, if it is a separate crate, who owns it.

[vityafx]

Also, I have not finished the proposal yet, because there are questions still.

[mark-i-m]

@vityafx We don't have to settle all questions now. Most RFCs do have an "unresolved questions" section for questions that should be decided before stabilization but after we have some experience using a feature.

[vityafx]

So I may go with my own vision and just put all the unresolved questions in the appropriate section of the rfc?

[mark-i-m]

Well, generally we want some kind of consensus about what we want to try, and part of that is reaching consensus about what questions we think can be resolved later... A large part of that is the OP's (your) original vision, but most RFCs do take a few edits and changes along the way :)

[Centril]

@eddyb I have to say that it is hard for me to imagine a practical scenario with non-const Limits... but with #2237 or a similar proposal we have our cake and eat it too, so no one gets limited?

[scottmcm]

we have our cake and eat it too

There is of course a small ergonomic cost to having both, since the const uses are now impl const Limits and where T: Const Limits and T::max_value() (instead of T::MAX).

[Centril]

There is of course a small ergonomic cost to having both

Sure; On scale I think I can personally live with that small cost =)