[libcxx-commits] [PATCH] D70346: [libc++] [LWG3321] Mark "year_month_day_last::day() specification does not cover !ok() values" issue as "Nothing to do", but add assertion.

[Howard Hinnant via Phabricator via libcxx-commits]

howard.hinnant added a comment.

This is part of a larger design philosophy for the entire library.  It is not necessarily a logic error to have a date or date component be in a state such that its `.ok()` returns false.  There is an example demonstrating this idea here:

https://github.com/HowardHinnant/date/wiki/Examples-and-Recipes#not_ok_is_ok

Additionally this part of the library is meant to be low-level and fast, without throwing exceptions, asserting, or otherwise terminating.  Debug mode for things is great.  But down at this level one can't assume that all clients want to pay for debug mode.  Some clients may have invariants in their code which make it logically impossible to `.ok() == false`.  Other clients may be using `.ok() == false` for other purposes (like a nan) as in the above example.  And still other clients might find value in layering a higher-level of software on top of `<chrono>` that adds a checks for `.ok()`, or for overflowing a `duration` or `time_point`, etc.  In order to serve all of these clients, `<chrono>` tries to do as little as possible (exceptions to this rule are `parse` where everyone wants every check possible).

Additionally my recommendation is not necessarily the highest quality choice.  For example returning a `!ok()` value of `day` might be desired by your clients.  Or if you know your hardware/compiler won't crash by indexing off the end of the array, maybe indexing off the end of the array //is// a good solution after all.  If you've got plenty of space, maybe indexing into an array 256 bytes is an option (assuming `month` is stored as an unsigned 8 bit byte).  Just leave diagnostics to a higher layer of software (that llvm may or may not provide).

There are several places in the spec where I've purposefully chosen unspecified behavior over undefined behavior (and this is one of them).  Here is another: http://eel.is/c++draft/time.cal.day.members#1.   I want the library to provide an expedient solution with no debugging, while not allowing the compiler to optimize the code out of existence.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70346/new/

https://reviews.llvm.org/D70346