Closed willtebbutt closed 2 months ago
Would it make sense for it to be a type parameter with two possible values, instead of a field? In other words, does it bring any benefit to have that information statically available?
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 100.00%. Comparing base (
d749b5a
) to head (00985ad
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Good question.
It shouldn't matter for performance, because whether or not a rule operates in safe mode is baked in when you call build_rrule
(extra code is injected during codegen to check pre- and post-conditions of every call to a rule that happens inside a derived rule on both the forwards and reverse passes -- this is propagated through the entire compiled function so that everything gets checked).
On a practical level, (I think) adding type parameters would technically be breaking, so it would be good to avoid if possible.
Okay then you can bump the minor version and I'll merge this
Great, thanks!
Tests only fail due to codecov throttling, merging now
Checklist
Additional context
Tapir.jl now has a "safe mode", in which lots of additional type checking is performed, in addition to some value checks. I would like to enable it by default (I'll be adding
@info
calls on the Tapir end to make it clear to users that they're using safe mode). This is to ensure that users are aware of this feature, which often makes debugging a lot easier, and can pick up on issues before they propagate to some arbitrary point further on in the code.Provided that people are happy with this, if someone could advise on the appropriate version bump for this package I would appreciate it.