-
Notifications
You must be signed in to change notification settings - Fork 21
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 empty ValidMode
and Prepare
#725
Conversation
Not sure how this PR leads to "thread |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The stack overflow is because Context::new()
and Context::default()
are mutually recursive. By using derive
you would fix this.
refs: &'a mut [bool], | ||
num_global_imports: usize, | ||
} | ||
|
||
impl<'a, 'm> ParseData<'a, 'm> { | ||
fn new(context: &'a mut Context<'m>, refs: &'a mut [bool], num_global_imports: usize) -> Self { | ||
impl<'a, 'm, M: ValidMode> ParseData<'a, 'm, M> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rust design question: Is there a good reason why the <'a, 'm, M>
after ParseData
couldn't be omitted? It seems redundant to write them since they could be inferred from the impl<'a, 'm, M: ValidMode>
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's because those are different things. ParseData
can take arbitrary parameters. If there would be a syntactic sugar it would be the opposite. You have to specify the ParseData
parameters, and any free variable would be universally quantified on the impl
. But I'm not sure this would help readability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you give an example where the struct has more parameters than impl
? Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's an example from the standard library.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! "universally quantified on the impl
" is a very good description.
refs: &'a mut [bool], | ||
num_global_imports: usize, | ||
} | ||
|
||
impl<'a, 'm> ParseData<'a, 'm> { | ||
fn new(context: &'a mut Context<'m>, refs: &'a mut [bool], num_global_imports: usize) -> Self { | ||
impl<'a, 'm, M: ValidMode> ParseData<'a, 'm, M> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's because those are different things. ParseData
can take arbitrary parameters. If there would be a syntactic sugar it would be the opposite. You have to specify the ParseData
parameters, and any free variable would be universally quantified on the impl
. But I'm not sure this would help readability.
The next step is to add
Verify
with optimizations.#46