[Proposal] Validation

[KathleenDollard]

Updates

Validation will be split between the core and a subsystem. Certain arity and other syntax issues need to be reported without the author including a subsystem because the parsing should be assumed incorrect when these errors occur. Other validation benefits greatly from the open subsystem concept where a core set of validation can be provided, with custom and ecosystem additions over time. We tried to unify and found these two sets of validations too fundamentally different.

Both validation mechanisms will use the same diagnostic system, so that error reporting does not need to distinguish between them. This is expected to be a DiagnosticDescriptor/Diagnostic. To simplify the common case of custom validation, there may be a general diagnostic for custom validation.
 

Earlier proposal

In the new pipeline design, there are at least two approaches to validation:

• Continue to have validation part of the parser, and keep a validation delegate on CliSymbol
• Have validation be a subsystem

This decision will have an impact on #2345 and #2346.

This proposal is to have the validation move to a subsystem.

Benefits of validation as a subsystem

• Validation rules are just like any other subsystem, lower concept count
• Validation subsystems can encapsulate common rules, such as string length.
• Validation will clearly occur after parsing and default values being applied
• The subsystem can hold symbol specific information for both declaration (a Func and/or rules for each symbol) similar to other subsystems, and could also hold extra information on the error. For example, if Roslyn diagnostics added a new property and we wanted to match that shape, it could be accommodated in the subsystem without affecting the parser
• If values could be set from defaults in a subsystem (there could be a default subsystem, whether it was the norm or a special subsystem), validation would need to be a subsystem to run after it. Put another way, if validation is in the parser and not a subsystem, we close the door for values being set from defaults in a subsystem.

Drawbacks of validation as a subsystem

• It is a bigger change from the previous version - .With style syntax will be needed
• This is a largely well known problem. If everything is done via a validation delegate, subsystems could manage rules by setting the validation delegate on the symbol
• Validation would require a pipeline or that the validation subsystem be explicitly called