[SERVER-53021] Directly define ScopeGuards: sunset makeGuard and ON_BLOCK_EXIT Created: 22/Nov/20 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Billy Donahue | Assignee: | Backlog - Service Architecture |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | sa-remove-fv-backlog-22 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Service Arch
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
KISS principle. There are 2 obsolete helpers used to define ScopeGuard variables. To define a ScopeGuard variable, you should write a ScopeGuard variable defintion. That's it. It's not special or magical, but these helpers give the illusion that it could be, and this is a distraction. makeGuard 203 occurrences. We have CTAD now and can replace both kinds of wrappers with a more conventional variable definition.
makeGuard is just a function to deduce the F for a ScopeGuard<F> definition. CTAD in C++17 makes most such "maker" functions obsolete. The only benefit of ON_BLOCK_EXIT at this point is to construct a dummy variable name to hold the makeGuard result. The other benefit it once had was to enforce that the object is bound to a variable, but [[nodiscard]] now does this for us. Engineers have to make up dummy variable names for other RAII objects all the time, and they manage to do it without using different macros for each RAII type. ScopeGuard definitions are not different from those other types. Yet the macro-use convention hints that something more is happening behind the scenes. It is not, so the macro is a redundant "moving part" to be eliminated. PS: A change was introduced to ScopeGuard that breaks CTAD but it could be brought back by reverting it or by adding this explicit deduction guide.
|