Yes, looks like a good first approximation. Looking at specification from the TS (aka P0052) – and off the top of my head maybe there maybe needs to be:
- constexpr on various functions (not in TS, but think should be now?)
- remove iostream include
- header should be scope - no
_guard(I wonder if in beman it should be without .hpp like standard?) - constructors are explicit in places in TS - aka:
template<class EFP> explicit scope_guard (EFP&& f)
- there’s some conditional noexcept logic on
scope_success(alsoscope_guard– more below)
scope_success() noexcept(noexcept(exit_function()));
- probably should explicitly disable assignment like in spec – should be anyway I think, but can’t hurt
scope_guard (const scope_guard &)=delete;
scope_guard & operator=(const scope_guard &)=delete;
scope_guard & operator=(scope_guard &&)=delete;
scope_guardshould be in a detail namespace - it’s not part of the api (more below)
Note that a pro-trick when I’m evaluating wording, I copy the synopsis from the paper and work with it until it compiles or doesn’t – so many bugs in wording discovered this way. My point being that what we’re doing here is a backward check of the specification by attempting to implement it.
So my 15 minute check of your implementation against the spec shines the light on at least a couple specification problems from P0052. Specifically
~scope_guard () noexcept(see below )
There’s no text corresponding to see below – in fact there’s almost no specification of scope_guard itself.
The intent in the wording is that scope_guard is exposition-only – that is not available to end users (hence my detail namespace comment above). But you don’t know that because it’s not marked properly as exposition only. Also in the wording it should be called scope-guard (uncompilable kebob case) - it’s just in italics…
Anyway, I think you should turn this draft into an initial PR on top of @river 's.