I understand that the macro only affects compile time but I’m talking about the extra function that’s included in the resulting source code when the macro is expanded during compile. Based on other feedback, it looks like the unused function is optimized away.
This was a great post, but is the last state of the macro actually bad for performance in any way? I get that it’s ugly (and we should only choose to make code less readable like this when there’s actually an issue) but is it worse for runtime performance?
Even if you were using the builder pattern, this maintains the immutable variable in the parent scope while you use the mutable variable’s builder pattern methods (basically exactly as my example demonstrates) in the inner scope.
edit: Oh, I think you mean you would chain the builder pattern calls and assign it to an immutable variable. Sure, that makes sense if you own the struct.
I prefer to encapsulate a mutable reference to the instance in a scope.
let post_form = {
let mut post_form = PostInsertForm::new(
// your constructor arguments
);
post_form.some_mutating_method(
// mutation arguments
);
post_form
};
This way you’re left with an immutable instance and you encapsulate all of the logic needed to setup the instance in one place.
The Majority Report. It’s awesome. https://m.youtube.com/@TheMajorityReport
Eternal Sunshine of the Spotless Mind
For those looking for more of the same great fun, please do yourself a favor and check out RiffTrax (link below). Done by the same guy.
I’ve literally sat down in city centers surrounded by buildings. It’s an amazing feeling.
I wish I could experience that. I wish our sci-fi fairytales of space travel were happening now. Alas, I must simply exist in a life lived better than a king of old, living longer than our ancestors, with food untasted by the billions before us, and all while I fly around in space within Eve Online while watching Star Trek. Life is great, but it’s so easy to want it to be just that much better.
What did he whisper in her ear?
The runoff voting downside is incorrect, the “drag the voters up to yellow and watch how it makes red win” example. This is not “see how making yellow more popular makes yellow lose”. It’s actually “see how making red more popular than yellow makes red win”. The movement of the voters is not for yellow, but for red and yellow in a way that gives more voters to red.
There is no way for yellow to be the only candidate to get a boost of voters in the demo. If there were, it would only demonstrate further that yellow would still continue to win.
Runoff voting is the way.
He gave them the weapons and is STILL giving them weapons today knowing exactly how they’re being used. “We’re trying to hard to stop this” while handing them the bombs they need to continue uninterrupted.
They say it just tastes better. idk. I’m going to try it soon.
Someone just suggested to me that I should be putting my chocolate bars in the freezer first. I’ve never heard of this, but apparently it’s a thing that I’ve been missing out on for a while.
So I guess I’m the one who can’t believe that I don’t do it.
After watching Pocahontas for the first time in many years, it shocked me that anyone could value personal wealth over coexisting. The antagonist only cares about mining out gold, looking at the hills as having potential as opposed to perceiving them as implicitly valuable as they are. Nature is worth protecting.
I loved both of these games as a kid.
Oh, okay. Thank you for clarifying. So doesn’t that mean we should never have a compiler written in the same language that it compiles? Why would we ever choose to make the mistake of using the same language? Is it ever not a mistake?
Why would a Rust compiler written in C be more trustworthy than one written in Rust?
If the idea is that, in an ideal world, we would compile each layer of compilers from assembly-up-to-Rust for each build, that seems even more risky as then you have to trust each compiler instead of just one.
I’m still lost on why they’re doing it.
The aliens haven’t yet consumed our planet in this timeline. Consider yourself lucky.