Conversation
|
|
||
| During the development of these sample implementations, it was observed that reintroducing the `scope_association` | ||
| concept from [@P3149R7] would yield several benefits: | ||
| In [@P3149R7], we also introduced the `scope_association` concept as an RAII handle for managing scope associations. However, this facility was removed in [@P3149R9] due to concerns about the unconventional behavior of its copy constructor. This change was made without implementation experience. |
There was a problem hiding this comment.
I'm a little hesitant to say "this change was made without implementation experience"; did we have experience with the association concept? We might have, but I don't remember.
There was a problem hiding this comment.
At the time of LEWG's approval of R9, I don't think we had an implementation of scopes with a scope_association concept. My recollection of when we discovered these issues was when we started working on R10 wording and realized the code looked gross. We then tried implementing the wording with a scope_association concept and realized it was way better.
Maybe I can be more explicit about the fact that because we didn't have implementation experience with scope_assocation at the time of R9's approval, the full consequences of its removal were not yet understood.
| ``` | ||
| :::: | ||
|
|
||
| In the above example, a key difference when implementing _`spawn`_ with a `scope_association` concept is that `t.try_associate()` is invoked in the constructor rather than in `run()`. This change simplifies exception handling within _`spawn`_: if an exception occurs, only the allocation needs to be explicitly cleaned up. By contrast, if `t.try_associate()` throws from `run()`, both destruction and deallocation needs to be explicitly handled. |
There was a problem hiding this comment.
I love this text, but I think it's wrong to italicize spawn, right? Or did you mean spawn-state?
| In the above example, a key difference when implementing _`spawn`_ with a `scope_association` concept is that `t.try_associate()` is invoked in the constructor rather than in `run()`. This change simplifies exception handling within _`spawn`_: if an exception occurs, only the allocation needs to be explicitly cleaned up. By contrast, if `t.try_associate()` throws from `run()`, both destruction and deallocation needs to be explicitly handled. | |
| In the above example, a key difference when implementing _`spawn-state`_ with a `scope_association` concept is that `t.try_associate()` is invoked in the constructor rather than in `run()`. This change simplifies exception handling within _`spawn-state`_: if an exception occurs, only the allocation needs to be explicitly cleaned up. By contrast, if `t.try_associate()` throws from `run()`, both destruction and deallocation needs to be explicitly handled. |
Update th wording with LWG feedback
Move simple_counting_scope::assoc-t into a class template in [exec.counting.scopes.general] and update the two scopes' assoc-t nested types to be nested type aliases to the newly-defined class template.
2 participants
No description provided.