Even if/when this is approved, lets wait to merge it until the other PRs are merged.

Oops, looks like this doesn't work -- I forgot about other issues with ordering. Looks like there's simply destructor issues now. Might have to go with the copy assignment implementation approach. I'll close it for now.

All right, I fixed it by using copy-and-swap (see updated description). I'd be interested in your thoughts on this approach. Additionally, how should the copy assignment operator be tested? Should we check that all member variables were copied correctly somehow? But then if we update the members, the test would have to be updated as well to catch the issue.

Additionally, how should the copy assignment operator be tested? Should we check that all member variables were copied
correctly somehow? But then if we update the members, the test would have to be updated as well to catch the issue.

Yes, I think that checking that all member variables were copied correctly would be the right approach. Maybe by implementing the == operator?

I'd be interested in your thoughts on this approach.

It's a neat and tidy solution. I was reading a bit about copy-and-swap. It would be interesting to see whether performance could be impacted when copying large transition systems.

Thanks for the review and for catching the missing member variable! I fixed that and implemented operator== for the test. That is a good point about large transition systems. In general, I'd like to have a discussion soon about how best to use transition systems.

Currently in the code, we mostly use references to avoid copies, but this can be cumbersome sometimes, especially when new systems are created. It also makes constructors complicated because often there's a lot of initialization happening there. We can include this in our next discussion. We can also use your profiling #94 to evaluate this.

Thanks for your update and including operator==, looks good to me! Yes, let's keep references vs. copies in mind for the next discussion.