Comment by tacitusarc

Comment by tacitusarc 17 hours ago

4 replies

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 17 hours ago

In 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 15 hours 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 2 hours ago

      IOW return something for the caller to validate.

      • deredede an hour 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.