Well, if you try the reborrow example from the article with edition=2015 and RUSTFLAGS='-Zpolonius=next', you will see that it does indeed work. So the answer is yes.
The first thing these articles must mention is in which nightly SPECIFICALLY will the switch be made. Because it didn't happen yet with the latest nightly, and (the PR that will flip the switch is not even merged yet ):
-Zpolonius=off
error: incorrect value `off` for unstable option `polonius` - either no value or `legacy` (the default), or `next` was expected
Also
NLL's analysis is flow-insensitive.
Polonius Alpha passes this because its analysis is flow-sensitive
Always ask two+ people to proof-read your announcements before hitting publish.
Nothing of significance will actually happen. The crate is too deeply intrenched in the ecosystem. And the little maintenance needed will be easily picked up.
Coming from C not C++, I actually didn't like chrono at first, but grew to be okay with it, and it gets the job done.
I had to stop reading very early. Sorry, but if you're going to do this topic, at least acknowledge the other very popular randomness crate, and argue why it wasn't good enough for what you wanted.
I think the other user meant that ls output is not supposed to be treated as parsable, because the tool doesn't offer any guarantees in that regards.
Shells have built-in support for globbing files anyway. xargs is also not needed. If someone is allergic to using a shell for loop, find always had -exec with ; instead + which wouldn't trip on too many arguments.
Later versions than C99 have no real added value proposition for the real use-cases where C is actually desired as an implementation language.
Later versions than C99 continue to introduce C++isms among other shit, from committee members some of whom probably never coded anything serious in C. This actually sometimes trickles down to compiler implementations even when you're sticking with an older version. So they manage to anger you even when you're keeping a distance.
Despite street myths and stereotypes, most people who choose C for some projects are not grey-hairs stuck in the past and incapable of learning new tools. Many of them in fact do use newer languages like Rust where they see fit. So there is no pressure to pick the one or two features from newer C versions that are maybe possibly can be useful.
Still, for some big projects that are kind of half-stuck with millions of lines of C, while at the same time having immense pressure to deliver maximum reliability AND security, these newer versions could proof useful at times. But the only project that comes to mind that fits this mold is the Linux kernel really. And there, non-standard language extensions are getting used anyway, so it's kind of an exceptional situation, that is also not very portable, but that's not a concern by the very nature of where a kernel sets in the stack.
Actually, I didn't notice your use of clone() which is even worse.
Here is what I had in mind. One can put the T: Default bound on the wrappers themselves to simplify, or add potentially expensive transformations for non-Default types.
Using cells in your solution is smelly, when you can simply use two transparent wrappers with Ref or RefMut access, so you have actual compile-time checking instead of janky checking at runtime (which is also not zero-cost).
The allow/deny variants could themselves hold & or &mut references too if we are going with that route. But it all depends on the precise problem OP is having and what is the best workable solution for it looks like.
Can you clarify/expand on what you mean.
Are the other objects of the same type (so are indeed Self)?
Are they in the same Vec or a different Vec or from different Vecs?
Are all the T's in your post the same?
...etc
it will always be ambiguous as implementations are hard to compare across languages
Correct.
in the transition for x86_64 they were seeing up to 70% increase in compile speeds
And that was a part of what I was hinting at, because you get >>70% speed-up with Cranelift in most Rust projects. But in either case, faster code generation is not free lunch, hence the mention of comparable runtime performance of generated binaries.
It's called a spam re-post.
Well, if you try the reborrow example from the article with edition=2015 and
RUSTFLAGS='-Zpolonius=next', you will see that it does indeed work. So the answer is yes.The first thing these articles must mention is in which nightly SPECIFICALLY will the switch be made. Because it didn't happen yet with the latest nightly, and (the PR that will flip the switch is not even merged yet ):
Also
Always ask two+ people to proof-read your announcements before hitting publish.
Did you mean editions?
Change your name to
Err::<!,!>(return).unwrap()Nothing of significance will actually happen. The crate is too deeply intrenched in the ecosystem. And the little maintenance needed will be easily picked up.
Coming from C not C++, I actually didn't like
chronoat first, but grew to be okay with it, and it gets the job done.That's not relevant when it's a question of interface.
fastrandhas a singleRngstruct that drives everything else. Was the option to replace the implementation details of this struct explored? No idea.Ctrl-F fastrand (0 results)
I had to stop reading very early. Sorry, but if you're going to do this topic, at least acknowledge the other very popular randomness crate, and argue why it wasn't good enough for what you wanted.
This is the way.
I think the other user meant that
lsoutput is not supposed to be treated as parsable, because the tool doesn't offer any guarantees in that regards.Shells have built-in support for globbing files anyway.
xargsis also not needed. If someone is allergic to using a shellforloop,findalways had-execwith;instead+which wouldn't trip on too many arguments.Later versions than C99 have no real added value proposition for the real use-cases where C is actually desired as an implementation language.
Later versions than C99 continue to introduce C++isms among other shit, from committee members some of whom probably never coded anything serious in C. This actually sometimes trickles down to compiler implementations even when you're sticking with an older version. So they manage to anger you even when you're keeping a distance.
Despite street myths and stereotypes, most people who choose C for some projects are not grey-hairs stuck in the past and incapable of learning new tools. Many of them in fact do use newer languages like Rust where they see fit. So there is no pressure to pick the one or two features from newer C versions that are maybe possibly can be useful.
Still, for some big projects that are kind of half-stuck with millions of lines of C, while at the same time having immense pressure to deliver maximum reliability AND security, these newer versions could proof useful at times. But the only project that comes to mind that fits this mold is the Linux kernel really. And there, non-standard language extensions are getting used anyway, so it's kind of an exceptional situation, that is also not very portable, but that's not a concern by the very nature of where a kernel sets in the stack.
Actually, I didn't notice your use of
clone()which is even worse.Here is what I had in mind. One can put the
T: Defaultbound on the wrappers themselves to simplify, or add potentially expensive transformations for non-Default types.Using cells in your solution is smelly, when you can simply use two transparent wrappers with Ref or RefMut access, so you have actual compile-time checking instead of janky checking at runtime (which is also not zero-cost).
The allow/deny variants could themselves hold
&or&mutreferences too if we are going with that route. But it all depends on the precise problem OP is having and what is the best workable solution for it looks like.Can you clarify/expand on what you mean.
Are the other objects of the same type (so are indeed
Self)? Are they in the sameVecor a differentVecor from differentVecs?Are all the
T's in your post the same?...etc
Thank you for spamming info about a 6 month old model just because it was posted in another instance you don't want people to use.
I replied on-topic there.
There should be a rule against low quality posts.
Vibe-coded trash + outdated models.
Wouldn't have expected anything better from a trash website.
the portable assembly meme
🤣🤣🤣🤣🤣🤣🤣
⚠TRIGGER WARNING⚠ two
tokio-rsrepos (this andtoasty) haveAGENTS.mdfiles.ABI is not something that gets "exposed" or not.
Correct.
And that was a part of what I was hinting at, because you get >>70% speed-up with Cranelift in most Rust projects. But in either case, faster code generation is not free lunch, hence the mention of comparable runtime performance of generated binaries.