-
Notifications
You must be signed in to change notification settings - Fork 33
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
Support () in expressions #25
Comments
Yes, allowing parenthesis seems like a good and reasonably simple idea. Do you want to implement it, or should I? |
I'm currently too busy, so please implement it if you can. |
Actually as long as |
I wasn't sure if incomplete parsing was a bug or a feature :) I'm assuming full parsing of arbitrary Rust expressions is relatively hard, and special-casing Parsing text as long as it matches Rust expression syntax seems problematic:
So rules for the expressions could be:
This way all expression parsing could be simplified to a tokenizer and checks for balanced |
Yes, avoiding surprises in what is considered a single expression or not gets complex faster than I thought it would. My original intent was that for a simple In the rules you suggest, is it only whitespace that is special, or operators as well? Would you consider |
Yes, breaking expression on operators could be OK. Or rather, instead of defining what ends the expression, it could be defined that at the "top level" (outside parens) only specific constructs are allowed (such as |
Basically, just handle nesting parenthesis, comments, and strings, and let the rust compiler sort everything else out in the generated code. Attempts to handle #25 .
Basically, just handle nesting parenthesis, comments, and strings, and let the rust compiler sort everything else out in the generated code. Attempts to handle #25 .
Ok, done, I think. The only thing I'm not certain about is that currently an arbitrary number of calls, indexes are allowed. Eg, if |
A chain of methods is certainly fine ( |
Yes, I think it will be hard to create a more limited syntax that is not too limited, so I think this is ok for now. So I think this issue is ready to be closed (the code is already merged). |
It works great, thanks! |
Changes since v0.3.16 includes: * Template syntax: - Allow local ranges (i.e. `2..7`) in loop expressions. - Allow underscore rust names. There is use for unused variables in templates, so allow names starting with underscore. - Issue #24 / PR #28: Allow logic operators in `@if ...` expressions. - Issue #25 / PR #27: Allow much more in parentehsis expressions. * Improved examples: - A new design for the framework examples web page, using svg graphics. - Improve code and inline documentation of iron and nickel examples. - Add a similar example with the Gotham framework. * Recognize `.svg` static files. * Allocate much fewer strings when parsing expressions in templates. * PR #26: use `write_all` rather than the `write!` macro in generated code, contributed by @kornelski * Fix `application/octet-stream` MIME type. Contributed by @kornelski. * Use write_str/write_all when generating output. Contributed by @kornelski.
As per #2 ructe does not reliably find whole Rust expressions. A workaround for that could be supporting
()
as a special case. Because Rust guarantees all parenthesis are balanced in valid expressions, ructe won't need to parse full expressions, just tokenize (to skip string literals) and balance parens.For basic arithmetic I'm working around this using
.saturating_add(1)
, but it's a bit silly.In some cases I also need more complex expressions, e.g. to convert
Option<String>
toOption<&str>
an ugly.as_ref().map(|s| s.as_str())
is needed, but this expression is too complex for Ructe.The text was updated successfully, but these errors were encountered: