Ah, that's right.

Personally I've used scan before; the mutability doesn't strike me as particularly unclean. The &mut there just avoids making the user return a tuple of both the new state and the thing to commit to the list. In fact, it is a good example of how you can restrict mutable references to well-defined scenarios.

Also, a hacky way to do a state machine is of course using a one-off enum defined in the scope, and using that as a state parameter for a fold, which can make a fold have more interesting behavior. I think generators and async functions compile with anonymous state machine enums as well, each variant corresponding to a wait/yield point.

Thanks! I originally wanted to do it all with the first iterator so that I didn't have to deal with the time of insert, but I quickly aborted out of that, since it probably would've been even messier. Shame that there's not a convenient way to define a state machine for iterators or something like that (or maybe there is in which case I'd really like to try it!).

Edit: Well after writing that, I thought about using Iterator::scan and maybe trying generators on nightly, but given that scan has mutable references as part of its design and generators are still in nightly it seems like they are also not quite ideal solutions.

statistically you'd have better luck asking people to just go ahead and punch themselves

I will punch anybody who votes this as 'best practices,' because I left the dbg! invocations in.

This is good. It's a shame that the iterator-based approach gets messy when you try to avoid the insertions of '-' and '.' at the end, though.

Thanks, that solved it for me

Yes, simply do not use PHP.

The only thing I really don't like about this challenge is the necessity of some boilerplate to obtain a list of prime numbers.
I know prime numbers don't pop out of thin air in the real world, but I get a little annoyed every time I have to copy one of these things in.
Altogether it seems like a pretty good problem, though.

Ah, I didn't know we had itertools.

I think this one is rather frustrating to a lot of people because we're used to thinking of physics problems in terms of floating point numbers.
What ended up working for me was adding 0.001 before I rounded to correct for a strange floating-point bias towards 0.
I guess I should've expected this when I decided to throw some f64 into my code. I'm not as mad as some other commenters here, but, yeah, this was frustrating.

This is why I think people should know math, and work problems out on paper before they fire up the editor.

Nope, this checks out. Yours probably only does a single string allocation, if my understanding of format!() is correct.

This is a 7 kyu problem, so the author likely assumes the challenger's conception of a string is not quite so complicated.