You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All the methods on the traits so far are associated functions.
So essentially the implementing struct is just a marker or container for organising the solutions. It has no use for any data or fields.
I'd like people to experiment with this idea, I have in mind fun implementations of Solution like this:
// from Advent of Code 2019pubstructIntcodeComputer{program:Vec<Instruction>,stack:Vec<i32>,register:HashMap<Register,i32>,}implSolution<Day2>forIntcodeComputer{fnpart1(&self) -> u32{// use the intcode computer and access its fields, methods!self.program.iter()// ...}}
We could even have mutability.
implSolution<Day2>forIntcodeComputer{fnpart1(&mutself) -> u32{// use the intcode computer and mutate it while solving the solutionself.stack.push(3)}}
The text was updated successfully, but these errors were encountered:
run might want to ensure each part gets a fresh IntcodeComputer by default.
These signatures are wildly different and incompatible with the current ones, and it won't always make sense to use one or the other.
There might be a need for separate traits, maybe Solution and Solve. I'd like for them to have nice readable names and avoid:
implSolutionMutSelf<Day2>forIntcodeComputer{
I also wonder if they could blanket impl each other in some way...
If something can solve with part1(&self) maybe part1() should just make a Self and then run part1(&self)?
All the methods on the traits so far are associated functions.
So essentially the implementing struct is just a marker or container for organising the solutions. It has no use for any data or fields.
I'd like people to experiment with this idea, I have in mind fun implementations of Solution like this:
We could even have mutability.
The text was updated successfully, but these errors were encountered: