Looking to example code in the README I have to say that it is neat! ❤️🔥
But know what? Could be awesome to support char-literals in the parser! macro. Currently in that example str-literals used as single-char strings.
I mean this for example:
num: num=<"-"? '0'-'9'+ …
Why there dash is str but not a char?
Also what about escapes, unicode sequences and binary literals?
There's no real need for character literals. They would behave exactly the same as string literals but only support a single character. And you can use escape sequences in the string literal, of course.
The two biggest things are lifetime extensions and inline consts. Both will allow you to write more concise code and, in the case of lifetime extensions, may help eliminate some bugs, since you won't need to work around that limitation anymore.
Yeah, I'm imagining, I've run into these problems in the past and then the compiler told me to do it differently and so I did. I'm definitely glad that such unobvious behavior is being reduced, I just probably won't realize until I'm writing similar code the next time and the compiler does not complain.
Inline consts also let you perform static assertions, like asserting a type parameter is not a zero-sized type, or a const generic is non-zero. This is actually pretty huge since some checks can be moved from runtime to compile time (not a lot of checks, but some that were difficult or impossible to do at compile time before).
I'm not really sure I get the usefulness of this absolute function. It still returns relative paths if the input was relative and it doesn't resolve "..". What would you use it for where canonicalize doesn't work for you?
unlike canonicalizeabsolute does not resolve symlinks and may succeed even if the path does not exist.
Primarily, the latter part is what I want. There's just sometimes situations where a path doesn't exist (yet), but you want to know what it would look like as an absolute path.
I'll assume you meant .., since ... is an ordinary filename. (Aside from the "who remembers ...?" feature introduced in Windows 95's COMMAND.COM where cd ... was shorthand for doing cd .. twice and you could omit the space after cd if your target was all dots.)
The reason it doesn't do that is that, when symlinks get involved, /foo/bar/.. does not necessarily resolve to /foo and making that assumption could introduce a lurking security vulnerability in programs which use it.
Hm it seems I misread the documentation there. I know why it doesn't resolve the ".." and that's fine, it just seemed very unnecessary in combination with my flawed understanding of the relative path handling.
Edit: and just to be snarky: I didn't type "..." I typed "..". ;)
I have no specific knowledge of this stuff. But the generic answer is an obvious one.
However Python code does it can be replicated in Rust.
For example, if python code executes the driver as a subprocess, then that too can be done in Rust.
So checking how Python code does it will probably lead to an answer to this question.
Maybe ask a web dev community about this.
There could be something better written in Rust.
There could be something better NOT written in Rust.
They should know.
but for example Vec::new() doesn’t highlight anything at all.
If I do Vec::new(foo, bar), I get expected 0 arguments, found 2 (rust-analyzer E0107).
but things like passing too many arguments into the println macro doesn’t throw an error.
I don't get that either, but I'm still running with the Vim configuration I setup on my previous PC from 2011, where I turned off checks that require calling cargo check or cargo clippy in the background. From what I remember, a properly functioning default rust-analyzer config should pick up and display anything cargo check will catch and you can switch it to cargo clippy for even stricter results.
Or how shown in this example, it did not autocomplete the clone method, while also just accepting .clo; at the end of a String (it also didn’t autocomplete “String”).
I get clone(), clone_into(), and clone_from() as proposed completions for .clo on my as-you-type completions for foo where let foo = String::new(); and it proposed a whole bunch of things, with String at the top when I typed Stri. (eg. the stringify! macro, OsString, mixed in with various results from other crates in the project like serde)
Turns out, the *.rs file needs to be in some kind of folder structure, like the one provided by cargo when creating a project. I was just editing the loose files in the rustlings program, and because they are not in a proper program folder structure, most of the syntax stuff didn't show up.
Thank you for sharing your experience though! It was very useful for figuring out if what I had was an issue or normal behavior. Now my neovim works perfectly with all the syntax highlighting I could wish for.
Ahh, yeah. In the beginning, Rust was built around the idea that individual files and invoking rustc are internal details, only relevant for integration into some other build system like Bazel, and that "normal" Rust projects need to be inside a Cargo project structure.
There is in-development work to have official support for something along the lines of rust-script, but it's still just that... in development. If you want to keep an eye on it, here is the tracking issue.
...and I could just as easily disparage those frameworks and give concrete reasons, but I don't. If you don't have something constructive to say, please be courteous and say nothing.
Aside from possibly making them feel better, it doesn't benefit anyone for them to drop into a topic about thing X and say nothing but "I use thing Y. I don't like thing X." and it wastes other people's time either scrolling past it or clearing out their RSS reader, depending on how they follow things.
@ssokolow rather than snarkily point out that the comment was not substantiated and dismissing it, you could also simply politely ask for clarification. "What is an aspect of React you don't like?"
Awesome! I've been tinkering with a project where i needed semi-advanced text parsing, and my homebrew solution is a barely functional mess, this looks perfect!
Depending on your preferences, there's also Nom if you prefer parser combinators, or lalrpop or grmtools if you prefer LR(1) parsing.
Since reading Which Parsing Approach by Laurence Tratt (author of grmtools), my plan for my own parsing projects has been to use an LR(1) parser generator for the stronger compile-time guarantees.
I didn't understand your sentence. But:
Having concerns is valid.
Having them in the context of this story/ad is misplaced.
IBM invested 1B$ in Linux all the way back in year 2000 (imagine how much that is worth with tech inflation), and they did it again years later.
That 1M$ is nothing. It's not nearly enough to control the Rust foundation for one year, let alone controlling the Rust project as a whole. Calling it a "Vote of Confidence in Rust's Future" was probably a good-spirited joke from the author, at least I hope it was.
Note that IBM still doesn't control Linux (even after acquiring RedHat), and we still have no problem calling them evil. Some of us still have no problem calling MS evil either, although many of the new crop of developers won't, because for them the chance to have the financial privilege of working there someday outweighs any moral considerations. Incidentally, there is a good intersection between this group, and the group that takes moral posturing about whatever in-group approved cause of the month to the maximum. Ironic, isn't it?
This is effective advertisement, not a donation. A real ad (with a campaign) would probably have cost much more, and wouldn't continue to be propagated for free months after the ad campaign is over, like this peace of news.
This type of ad is also much harder to filter/block, since not only it appears to be site-native, but also topic-native.
Rust Programming
Hot