You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I tried porting an existing app from System.CommandLine 2.0.0-beta4.22272.1 (commit 209b724) to 2.0.0-beta4.23073.1 (commit 6524142). Because of #1994, it is no longer possible to initialize a static field like this:
Add a private static Option<FileInfo> CreateOutputZipFileOption method and call that in the initializer.
Explicitly define a static constructor that initializes the fields. This loses the beforefieldinit flag but that seems unlikely to matter for performance because the initialization would have been done during startup anyway.
Make the fields not static, and initialize them in an instance constructor.
Replace the fields with local variables, and reference them from a lambda or a local function so the C# compiler lowers them to fields again.
That would be more convenient to use, but more difficult to discover. The documentation of the Validators property could reference it, though. It might even have been possible to guide the Intellisense feature of Visual Studio to it by using the completionlist element in the XML documentation comments of ValidateSymbolResult<T>, if that type had not been removed in #1944 / #1946.
I tried porting an existing app from System.CommandLine 2.0.0-beta4.22272.1 (commit 209b724) to 2.0.0-beta4.23073.1 (commit 6524142). Because of #1994, it is no longer possible to initialize a static field like this:
Instead, one can do any of the following:
private static Option<FileInfo> CreateOutputZipFileOptionmethod and call that in the initializer.beforefieldinitflag but that seems unlikely to matter for performance because the initialization would have been done during startup anyway.Could the library instead allow this syntax:
That would be more convenient to use, but more difficult to discover. The documentation of the
Validatorsproperty could reference it, though. It might even have been possible to guide the Intellisense feature of Visual Studio to it by using thecompletionlistelement in the XML documentation comments ofValidateSymbolResult<T>, if that type had not been removed in #1944 / #1946.