2 ms·
Structs are representations of combinatorial types! In your file case, you could parse the input into a struct, and then accept or reject further processing bas
by tacitusarc 1y ago
Structs are representations of combinatorial types! In your file case, you could parse the input into a struct, and then accept or reject further processing based on that contents of that struct.
Of course, it would be reasonable to claim that the accept/reject step is validation, but I believe “Parse, don’t validate” is about handling input, not an admonition to never perform validation.
- mrkeen 1y agoIn pure C however, you still get the types-in-source-code explosion, for lack of parametric polymorphism. You need an email_or_error and a name_or_error, etc. The alternative is to fake PP with a void*, but that's so ugly I think I'd scrap the whole effort and just use char*. > I believe “Parse, don’t validate” is about handling input, not an admonition to never perform validation. It's about validation happening at exactly one place in the code base (during the "parse" - even though it's not limited to string-processing), so that callers can't do the validation themselves - because callers will validate 0 times or n>1 times.
- deredede 1y ago> You need an email_or_error and a name_or_error, etc. You don't need that. A practical solution is a generic `error` type that you return (with a special value for "no error") and `name` or `email` output arguments that only get set if there's no error.
- mrkeen 1y agoIOW return something for the caller to validate.
- deredede 1y ago"Parse, don't validate" is a catchy way of saying "Instead of mixing data validation and data processing, ensure clean separation by first parsing 'input data' into 'valid data', and then only process 'valid data'". It doesn't mean you should completely eliminate `if` statements and error checking.