refactor: use explicit &util::TraceThread function pointer in thread spawns #34736

1. 
   arejula27 commented at 10:20 pm on March 4, 2026: none

   Replace implicit function-to-pointer decay with explicit &util::TraceThread expressions in two thread spawn call sites.

   Why: While both forms work the same way, using explicit & is slightly more friendly to the compile, makes the code easy to understand what is happening, and the rest of the project already follows this style for thread spawns. This aligns these two occurrences with that convention. All threads which uses util::TraceThread to spawn now use the explicit & form Verified no remaining inconsistent spawns:

   0# no remaining inconsistent spawns
   1$ grep -rn "std::thread(util::TraceThread" src/ | wc -l
   20
   3# all occurrences now use explicit & form
   4$ grep -rn "util::TraceThread" src/ 
   

2. fix: solve traceThread inconsistency d9548da0e0
3. DrahtBot added the label Refactoring on Mar 4, 2026
4. 
   DrahtBot commented at 10:20 pm on March 4, 2026: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Reviews

   See the guideline for information on the review process. A summary of reviews will appear here.

5. 
   maflcko commented at 6:36 am on March 5, 2026: member

   Why: While both forms work the same way, using explicit & is slightly more friendly to the compiler as it removes any ambiguity,

   Can you explain this? What ambiguity? What is a possible way this can fail here in this context?

   and the rest of the project already follows this style for thread spawns.

   I think it is fine to fixup the style as part of another pull request in that area/topic. But a stand-alone pull to add or remove redundant & probably isn’t needed, when either version is perfectly fine and harmless.

6. 
   arejula27 commented at 7:35 am on March 5, 2026: none

   Why:

   Can you explain this? What ambiguity? What is a possible way this can fail here in this context?

   The ambiguity is for the person who is reading the code, bad writing let me correct it

   and the rest of the project already follows this style for thread spawns.

   I think it is fine to fixup the style as part of another pull request in that area/topic. But a stand-alone pull to add or remove redundant & probably isn’t needed, when either version is perfectly fine and harmless.

   Fair, I was studying the concurrency in the project and saw the inconsistency, thought it could be a interesting fix, however as I mentioned it is just stylish change. The pr can be closed if this is not the way to refactoring

7. 
   maflcko commented at 7:42 am on March 5, 2026: member

   Thx, yeah, I think I’ll close it for now. If another reviewer sees any value in this, it will be trivial to re-open after a comment.
8. maflcko closed this on Mar 5, 2026

   ---

Contributors
arejula27 DrahtBot maflcko

Labels
Refactoring