Doubly linked list is one of std's collections. And safety in Rust is built on top of unsafely, because there is no way around that.
Did you try to actually look up literally anything before asking?! Because simply checking out std::collections docs would have given you some answers.
^Who^ ^memory-holed^ ^2021^ ^an^ ^why❔😉^
They talk too much. But almost none of them actually code or know how to at a good level.
We have someone just like that here.
Now that others got all the technicalities out of the way, maybe ChromeOS/ChromiumOS would be something along the lines of what you're looking for? not that anyone should choose to daily-drive it.
That's exactly the communicated meaning I was concerned an oblivious reader might get. You can use an updated Rust compiler 10 years in the future while your crate is still on 2015/2018/2021 edition. Editions are NOT software versions.
I might expect the Rust ecosystem to adopt these new features.
This again points to you maybe not understanding how editions work, or maybe I'm just reading it wrong again. But you "upgrading" has no effect on your dependencies, and vise versa (except indirectly if MSRV is a factor as another user mentioned).
Just upgraded
Weird wording!
Maybe it's just me, but this may give the impression that it's something that is strictly needed, or will provide any immediate improvement, which is not the case, unless you're still actively working on these projects and plan to use/depend on features/behaviors required by the new edition.
In case the wording tripped anyone, generators (blocks and functions) have been available for a while as an unstable feature.
This works (playground):
#![feature(gen_blocks)]
gen fn gfn() -> i32 {
for i in 1..=10 {
yield i;
}
}
fn gblock() -> impl Iterator<Item = i32> {
gen {
for i in 1..=10 {
yield i;
}
}
}
fn main() {
for i in gfn() {
println!("{i} from gfn()");
}
for i in gblock() {
println!("{i} from gblock()");
}
}
Note that the block-in-fn version works better at this moment (from a developer's PoV) because rust-analyzer currently treats gfn() as an i32 value. But the block-in-fn pattern works perfectly already.
Hey, posting from Coping People's Party is cheating.
/mj Let's keep the language used in your description to the chans. It's a jerking style violation anyway.
While you missed the mark here since typst has all the important stuff open (I wouldn't use the web interface even if it was free/open source), I appreciate that you're keeping an eye open.
If you were in r*ddit's rust community a few years ago, you probably would have been banned, just like me😄
A blog post from M$ mentioning Rust with zero code
=> straight to the top
A news article regurgitating the same thing a week later
=> straight to the top
Another news article two weeks later regurgitating the same thing, possibly with the addition of a random tweet from some M$ dev
=> straight to the top
Anyone not sucking nu-M$'s ****
=> banished to the bottom, or worse.
Things got so silly to the point where I made this jerk post (archive link) about one of these silly posts.
I wouldn't correct you if this was a general community where the internet gantry hangs in numbers like the multiple !linux communities, but let's keep things more factual here in !rust.
After Wedson quit months ago, no one from the Rust-For-Linux effort has quit/resigned/whatever. No one quit who is relevant to current mainline kernel development in general, either.
There is a difference between the actual Rust-For-Linux team, and Rust proponents who may write kernel code out-of-tree, or may happen to still be listed as maintainers in a dead poor GPU driver. Confusing the two is good for drama, but let's not do that here.
And the bad boy maintainer is entitled to his opinion (which I disagree with of course). An opinion which will always be more informed and relevant than 99.999% of whatever the internet gantry has been contributing.
We went from spam "news sites" to spam videos. Maybe an "original source" policy should be applied by moderators!
This applies to both hare and on [email protected]