Should `History` be a validator solely, or should it be a fixer?

[rsenne]

See discussion on #78.

This would be a breaking change, but we aren't at major version 1 yet, so allowed under semantic versioning. If we decide to go this route, we should do a deprecation cycle anyway until v1.0.0 lands imo

[JoseKling]

I agree with your points from before. We can just throw an error if the conditions for defining a History are not met. This will incur in some negligible overhead and give us more guarantees. One issue that I thought about is that, not only for us, but if the user is implementing some custom method, it is useful to have these errors.

So, what are the checks we need to make for validation? Anything else apart from the ones below?

• Ordering of the event times
• Check for repeated event times (missing)
• Check if all events are inside [tmin, tmax)
• Check if the length of the marks array is the same as of times
• Check the dims vector (when provided) has any values outside the number of dimensions of the process

I don't think there is any need to provide other methods to fix anything, because a History would, by design, have these properties, and it is nothing complex that the user can't easily fix by themselves.