Hi Ville – welcome! I’m sure we’ve met somewhere ;). I appreciate the thoughts. Scope is my side project that’s been sitting untouched for awhile, but I’d like to get it into the conversation for Brazil.
You’re in line with pretty much what I’ve been thinking. If we looked at core guidelines they really only have scope_guard. success and fail, with coroutines is for sure a potential problem and I agree that just removing them makes sense.
I’m also not a fan of the release function on the guard for the 95% case. It inhibits code readability for one thing – if I see a guard that doesn’t support release – then I can jump to the end of block immediately knowing where things will be released. That also means you don’t need a bool in the guard to handle that check. Instead of this I’m thinking of something more like this
template<class F, class Condition = ...>
class scope_guard;
...
~scope_guard() noexcept {
if (Condition::execute())
std::invoke(fn_);
}
Then an advanced user can customise the condition if they so choose, but otherwise the default case is to always executed the function. boost.scope does something like this.
Noted on the CTAD instead of make factory – also we need to concept constrain the callable I’d say.
But am I understanding that you’re suggesting just having for unique_resource?