-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Add more functionality to where clause #2715
Comments
I think this falls under const-generics, although with a different syntax. |
I don't think so, with fn foo(port: usize)
where port <= 65535,
port > 1000,
port in 1000..65536 // or this one, much better
{} compile-time range check, you can reduce several jumps(conditional jump) in final generate, just because in order to compile-time range check, you need know the param value on the compile time, don't same with const-generics at all |
That is the same as const-generics once it gets extended with where clauses, fn foo<const port: usize>()
where port <= 65535,
port > 1000,
port in 1000..65536 // or this one, much better
{} Right now const generics can't do this, but they should be able to once they get extended later. |
@KrishnaSannasi in the RFC, I didn't see any about where clause range check thing, my proposal is only relevant to where clause, make it more general purpose |
That is true, in the discussion for the RFC, these where clauses were considered and postponed until after we got const generics. Implementing these where clauses is a large effort, and can only be done after const generics, specifically after we stop treating expressions in const generics as black boxes. I wasn't trying to discourage this, just noting that this seemed to be related to const generics, sorry if I gave the wrong impression. |
Here is an issue that links to other issues about refinement types. They don't us the If you are just interested in speed, then it may help to add an |
Sounds like Haskells guard expression, in your examples above just
That's it, we will have this instead, moreover thing you are proposing is actually the same. |
This might allow/help tools to do formal verification of code. Even if there are no runtime checks (at least in release mode), e.g. Hoare-logic and wp-calculus comes to my mind here:
and every call of this function could be back traced so that every value, that might end up in this call, is guarantied to be in this range. I have read this pdf and I think, it might be useful to implement this into the language itself in an optional manner, even if the compiler usually ignores these annotations. |
This is an interesting idea but I would prefer we get In Haskell, you typically use the |
Regarding #2715 (comment), this syntax conflicts with type ascription when parsing. macro_rules! x {
($i:item) => {}
}
macro_rules! y {
(fn f() where $e:expr, $f:expr,;) => {}
}
x! {
fn f()
where
A: B + C<D, E>::F,
;
}
y! {
fn f()
where
A: B + C < D,
E > ::F,
;
} This is also why #1932 chose the where
const { A: B + C < D },
const { E > ::F },
A: B + C<D, E>::F, |
The where clause is compile-time check, it's a great idea. but I think we can make it even more great by add some more functionality to it.
The text was updated successfully, but these errors were encountered: