I like the idea, but it's there's not really a pointed quote in that comment I think.^^ Maybe except for this part.
But what's the point of a const function then?
It makes code like this compile:
const FOO: i32 = my_const_fn(13);
That code is rejected unless
my_const_fn is a
const fn .
That is the
const has on
fn . There is no effect on optimizations or runtime code.
(Slightly edited as well.) But still that's rather long. And we're starting to artifically construct a quote rather than take a real one.^^
I don't know if it qualifies for quote of the week but I'm glad it was posted here so I could read it
@zrk are you perhaps shocked by it like me and another member did, thinking that
const can allow generating better code without side effects?
In response to
In this mesh class, what's wrong with my use of lifetimes? - #4 by trentj
Many hours of discussion with the borrow checker leads me to concur with
@alice, relevant to every Rust nauplius who attemps self-referential structs. (emphasis added) From How to resolve "error[E0499]: cannot borrow ... as mutable more than once at a time" in this case - #3 by alice
When you have a lifetime
<'a> on a struct, that lifetime denotes references to values stored
outside of the struct. If you try to store a reference that points inside the struct rather than outside, you will run into a compiler error when the compiler notices you lied to it.
Slightly OT here, but should that compile error say something about self-referential structs?
Figuring out the exact conditions is probably difficult, but I think it would be a good idea.
There's no magic to how we solved the memory management issues.
clone() is your friend when conversing with the borrow checker.
Don't put references in your structs.
Don't share mutable data; use a channel to send changes to its owner.
Don't worry about performance until you have a performance problem.
You can probably infer the last one from the first three.
Sage advice for anyone programming in Rust: first get it working correctly, then measure, then tune performance only if necessary.
The whole post is worth reading, I'd say
for those wanting to discuss about it / challenge that assertion, the
quote of the tweek thread is not for that. Instead, take advantage of there being
a dedicated thread for it.
Unfortunately it's from the survey, so I don't know who to attribute it to, but this made me chuckle:
[...] clippy is for people who find a certain emptiness inside when they finally get code through the compiler.
And it's true that a lot of stuff requires a "sufficiently smart compiler" but really it's 2020, if your compiler isn't serving you breakfast in bed you need to be upping your expectations.
Jubilee on the Rust Zulip
Historically, C has been the best fit for these applications just because it so lean: by providing essentially nothing other than the portable assembler that is the language itself, it avoids the implicit assumptions (and girth) of a complicated runtime. But the nothing that C provides reflects history more than minimalism; it is not an elegant nothing, but rather an ill-considered nothing
Bryan Cantrill on what no_std is competing with
Alternative title: mediocre C++ is arguably worse than mediocre rust.
I’d agree with that? I think the power and danger of C++ is that it assumes the programmer knows best. Rust assumes the programmer is wrong if it looks dangerous. So.. yes?
sesuximo in C++ still isn't cutting it | Hacker News
Think of it like this: When Rust passes control to C it's like you jumping into a pit full of vipers in the hope that none of them bytes you. I might put up a sign "unsafe, vipers in pit".
ZiCog in Does Rust offer C interop? - #4 by ZiCog
We need all that knowledge of what the problem space looks like to evaluate if a simple API is good enough, but we do not necessarily need all that knowledge reflected directly in the API surface.
Ralf Jung on the
Safer Transmute RFC
To me this feels like a core insight on effective API design: map out the problem space, survey existing approaches, create a minimal solution. Then iterate from there.