"Parse, don't validate" through the years with C++

Join the discussion

• Hacker News
• First thought, assuming that birth year starts at 1900 is bad for a number of reasons; one of which, "process this list of authors and ..."

  What about everyone born before 1900?

  by jsymolon
• Author has used LLMs to generate Java code in C++. It detracts from his point.
  by bregma
• I don't see how this is in any way preferable to having an ordinary default constructor that does the same thing:

      // There are a few ways to let API callers bring their own 
      // memory, as they would in a no-malloc environment and this
      // stack-friendly c'tor is a stand-in for that. 
      static Birthdate epoch() { return Birthdate(1900, 1, 1); }

  by usefulcat
• Heh, I can especially tell the first code example is LLM-generated. Humans don't usually write comments like:

     // There are a few ways to let API callers bring their own 
     // memory, as they would in a no-malloc environment and this
     // stack-friendly c'tor is a stand-in for that. 
  

  There's just something about this comment that doesn't feel right. I've seen these kinds of phrasings in LLM output before but I'm not sure exactly how to describe them.
  by MarsIronPI
• The C example could have implemented a lot of validation just by checking the return value of sscanf():

      if (sscanf(user_input, "%4u-%2u-%2u", &year, &month, &day) != 3) {
          // return an error
      }
  

  This still does not catch trailing garbage, but you could check for that as well:

      if (sscanf(user_input, "%4u-%2u-%2u%c", &year, &month, &day, &dummy) != 3) {
          // return an error
      }
  

  The result would be 4 if there was at least one trailing character. Too bad there is still no std::scan() companion to C++23's std::print().
  by gsliepen
• The second sentence of your summary is fine, but I don’t like the first sentence:

  > Use your language’s type system to parse unstructured inputs.

  We don’t use the type system to parse. We use the type system to provide evidence (also called a proof or a witness) that parsing was successful, and we rely on the language’s access control facilities (public/private) and the soundness of its type system to prevent fabrication of false evidence.

  by mayoff
• It seems like the C++98 example is the best by far? Keeps all error information while remaining concise and easy to understand. Not to mention 50 times faster. (Could be improved by adding some simple type aliases like BirthYear that explicitly start from 1900.)

  IMO the main takeaway is that malformed input is not an exceptional state when parsing, and should be treated as a first class citizen. Everything else is yak shaving how you want to handle the (status, validObject) tuple coming from the parser.

  by foobar1726
• The C++11 example is the weakest in the article by its own thesis. Public throwing constructor, no year check, no leap-year check, so Birthdate(0, 2, 30) constructs cleanly. The C++17/23 shape (private ctor + static factory) is the actual mechanical insight from King's essay. Make the constructor a function that can fail, so the type itself carries the proof.
  by _alphageek