`init` accessor of CliAction.Terminating cannot be called in C# 7

[KalleOlaviNiemitalo]

#2205 changed the CliAction.Terminating property from { get; protected set; } to { get; protected init; } here:

command-line-api/src/System.CommandLine/Invocation/CliAction.cs

Lines 15 to 18 in 104bb34

	/// <summary>
	/// Indicates that the action terminates a command line invocation, and later actions are skipped.
	/// </summary>
	public bool Terminating { get; protected init; } = true;

The init accessor cannot be directly called in C# 7; it requires at least C# 9. That makes the property difficult to initialize in these cases:

• When targeting .NET Framework, where Microsoft does not support C# 8.
• When the application must remain buildable in Visual Studio 2017 (whose support ends in April 2027).

#1586 was a similar issue about the init accessor of Option.Arity, fixed in #1595 by changing to set.

[KalleOlaviNiemitalo]

In 2.0.0-beta7, the offending property is CommandLineAction.Terminating:

command-line-api/src/System.CommandLine/Invocation/CommandLineAction.cs

Line 18 in dbc3781

public bool Terminating { get; protected init; } = true;

In the upcoming 2.0.0-rc1, it's being paired with a new CommandLineAction.ClearsParseErrors property, which is virtual read-only, rather than init-only:

command-line-api/src/System.CommandLine/Invocation/CommandLineAction.cs

Line 24 in e863869

public virtual bool ClearsParseErrors => false;

I think CommandLineAction.Terminating could be reimplemented in a similar way:

public virtual bool Terminating => true;

Then, EnvironmentVariablesDirective.EnvironmentVariablesDirectiveAction would override Terminating to return false, instead of setting it in the constructor here:

command-line-api/src/System.CommandLine/EnvironmentVariablesDirective.cs

Lines 32 to 36 in e863869

	internal EnvironmentVariablesDirectiveAction(EnvironmentVariablesDirective directive)
	{
	_directive = directive;
	Terminating = false;
	}

It would be a breaking change though.

[jeffhandley]

Great suggestion, @KalleOlaviNiemitalo. We would need to assess the breaking change impact potential, @jonsequitur @baronfel.

1. This would be a binary breaking change, correct? Without a fully coherent build, runtime exceptions could occur if running against a version of the assembly that is different from what a dependency was built against; is that right?
2. The break would only occur if a derived type was utilizing the protected init to set the value, and those derived types would have to react by overriding the member instead; correct?

Since this would address a regression that prevents usage with C# 7, I'm supportive. Once we have the breaking change details understood, we can get a pre-review from Tactics.

[baronfel]

@jeffhandley we should investigate the impact of the change by making it in the VMR right now on a branch. The difficulty of that will be a good proxy for the overall risk IMO.

[KalleOlaviNiemitalo]

Searching for Terminating in dotnet/dotnet shows these uses in other projects that would need to change:

• src/sdk/src/Cli/dotnet/Parser.cs: PrintCliSchemaAction, for dotnet --cli-schema.
• src/sdk/src/Cli/dotnet/Commands/Workload/WorkloadCommandParser.cs: ShowWorkloadsInfoAction, for dotnet workload --info.
• src/sdk/src/Cli/dotnet/Commands/Workload/WorkloadCommandParser.cs: ShowWorkloadsVersionOption, for dotnet workload --version. Users may expect this to override ClearsParseErrors as well.

Actually, all three are assigning Terminating = true, which is already the default, so they wouldn't need to override Terminating at all.