From 41f6bd437eac23abe4f2706b8f24eebb06766daf Mon Sep 17 00:00:00 2001 From: ZjzMisaka Date: Tue, 14 Apr 2026 10:55:09 +0800 Subject: [PATCH] docs: Document rationale for QueueWorkItem overloads Add an XML summary to PowerPool explaining the design choice to provide many QueueWorkItem overloads. The comment notes the intent to keep the API strongly typed without a source generator (trading binary size for ease of use) and cites similar brute-force overloading patterns in the .NET runtime (Tuple/Action/Function) as precedent. This is a documentation-only change in PowerThreadPool/Core/PowerThreadPool.QueueWorkItem.cs. --- PowerThreadPool/Core/PowerThreadPool.QueueWorkItem.cs | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/PowerThreadPool/Core/PowerThreadPool.QueueWorkItem.cs b/PowerThreadPool/Core/PowerThreadPool.QueueWorkItem.cs index f6d23d6..8675a8b 100644 --- a/PowerThreadPool/Core/PowerThreadPool.QueueWorkItem.cs +++ b/PowerThreadPool/Core/PowerThreadPool.QueueWorkItem.cs @@ -9,6 +9,16 @@ namespace PowerThreadPool { + /// + /// There are a great many overloads of QueueWorkItem, but this is the conventional .NET approach. + /// I want to keep the API strongly typed without introducing a source generator, + /// so I’m trading space for ease of use. + /// Considering that: + /// https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Tuple.cs + /// https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Action.cs + /// https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Function.cs + /// all use a similar brute-force overloading pattern, I think this is unavoidable. + /// public partial class PowerPool { private long _workIDIncrement = 0;