C++ Logo

std-discussion

Advanced search

Re: Some feedback on scope guards

From: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>
Date: Fri, 14 Apr 2023 00:56:24 +0200
pt., 14 kwi 2023 o 00:16 Ville Voutilainen via Std-Discussion
<std-discussion_at_[hidden]> napisaƂ(a):
>
> On Fri, 14 Apr 2023 at 01:12, Edward Catmur <ecatmur_at_[hidden]> wrote:
>
> >> > The thing is, it is possible for scope guard destructors to detect how they were called. We just have to give up composability, which honestly doesn't seem like that much of an issue - why would you want to put a scope guard inside another object or in dynamic storage?
> >>
> >> To give RAII semantics to types that don't have them internally,
> >> without having to write holder types. If that's the price of getting
> >> coroutines to work, to lose the ability to do that, then you can burn
> >> coroutines for all I care.
> >
> >
> > If it's for RAII, then plain scope_guard should be fine (even if a bit misused; a class type is not a scope). scope_success and scope_failure would not make much sense as data members unless you're writing another success/failure scope guard class (what I meant by composability).
>
> That I can probably live with.

But why can't it compose? We need to propagate compile time
information. We already have propagation when we use `const` methods.
I previously suggest using `requires` for this but it could be a new
contextual keyword like:

```
//Foo.h
class Foo
{
    X x;
    ~Foo() scope_fail;
    ~Foo() scope_success;
};
```
As this keyword is part of a signature, in other compilation units we
still know what context it is.
```
//Foo.cpp
Foo::~Foo() scope_fail
{
};
```
Now `X` could calls `X::~X() scope_fail;` or if it does not exist then
`X::~X()`.
Only problem is that you need to propagate "scope" for the whole hierarchy,
the same as we need to propagate `const`.
Interesting case would be `std::optional<Foo>` (or other containers)
but this could be handed by
calling the destructor directly like `x.~Foo() scope_fail;`.

This would need update of std types but it should not be breaking changes
as a new specialid destructor could be behind `requires` and new type trait.

> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion

Received on 2023-04-13 22:56:37