After reading up on various implementations and studying design options I think that inactive guards should be removed from the design. This issue is to implement that change.
Inactive guards can occur as a resuilt of move construction or a call to release. The implications of these decisions are that the guard must store a boolean flag for the activation state and a check on destruction before calling the ExitFunction. The existence of these facilities also makes reasoning about code using scope more difficult since code readers must now process the entire scope to see of the guard has been released. Not that release is omitted by other implementations, notably GSL.
After reading up on various implementations and studying design options I think that inactive guards should be removed from the design. This issue is to implement that change.
Inactive guards can occur as a resuilt of move construction or a call to release. The implications of these decisions are that the guard must store a boolean flag for the activation state and a check on destruction before calling the ExitFunction. The existence of these facilities also makes reasoning about code using scope more difficult since code readers must now process the entire scope to see of the guard has been released. Not that release is omitted by other implementations, notably GSL.