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
In the new pipeline design, there are at least two approaches to validation:
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
Drawbacks of validation as a subsystem
.Withstyle syntax will be needed