coverage: 98.936%. remained the same
when pulling bbf4456 on ajfriend:aj/error_max
into b29d820 on uber:master.

Alternatively, AI suggested something like this:

typedef enum {
    E_SUCCESS = 0,
    E_FAILED,
    E_DOMAIN,
    /* ... */
    E_DELETED_DIGIT,
    E_COUNT  // sentinel for iteration and sizing
} H3ErrorCodes;

#define H3_ERROR_MAX (E_COUNT - 1)

Alternatively, AI suggested something like this:

typedef enum {
    E_SUCCESS = 0,
    E_FAILED,
    E_DOMAIN,
    /* ... */
    E_DELETED_DIGIT,
    E_COUNT  // sentinel for iteration and sizing
} H3ErrorCodes;

#define H3_ERROR_MAX (E_COUNT - 1)

We could use E_COUNT directly then no? (I also had a similar idea when adding E_INDEX_INVALID but wasn't sure as then it can be referenced externally - though maybe people would want a similar constant)

@isaacbrodsky, any thoughts on which approach you'd prefer?

Alternatively, AI suggested something like this:

typedef enum {
    E_SUCCESS = 0,
    E_FAILED,
    E_DOMAIN,
    /* ... */
    E_DELETED_DIGIT,
    E_COUNT  // sentinel for iteration and sizing
} H3ErrorCodes;

#define H3_ERROR_MAX (E_COUNT - 1)

We could use E_COUNT directly then no? (I also had a similar idea when adding E_INDEX_INVALID but wasn't sure as then it can be referenced externally - though maybe people would want a similar constant)

Yeah, I suppose we could do something as simple as:

typedef enum {
    E_SUCCESS = 0,
    E_FAILED = 1,
    E_DOMAIN = 2,
    /* ... */
    E_OPTION_INVALID = 15,  // Mode or flags argument was not valid
    E_INDEX_INVALID = 16,    // `H3Index` argument was not valid
    H3_ERROR_SENTINEL  // sentinel for iteration and sizing
} H3ErrorCodes;

@isaacbrodsky, any thoughts on which approach you'd prefer?

We do something similar here:

Alternatively, AI suggested something like this:

typedef enum {
    E_SUCCESS = 0,
    E_FAILED,
    E_DOMAIN,
    /* ... */
    E_DELETED_DIGIT,
    E_COUNT  // sentinel for iteration and sizing
} H3ErrorCodes;

#define H3_ERROR_MAX (E_COUNT - 1)

We could use E_COUNT directly then no? (I also had a similar idea when adding E_INDEX_INVALID but wasn't sure as then it can be referenced externally - though maybe people would want a similar constant)

Yeah, I suppose we could do something as simple as:

typedef enum {
    E_SUCCESS = 0,
    E_FAILED = 1,
    E_DOMAIN = 2,
    /* ... */
    E_OPTION_INVALID = 15,  // Mode or flags argument was not valid
    E_INDEX_INVALID = 16,    // `H3Index` argument was not valid
    H3_ERROR_SENTINEL  // sentinel for iteration and sizing
} H3ErrorCodes;

This last one looks the "best" to me because (1) it's obviously different from the rest because it doesn't get a number assigned and it doesn't start with E_ and (2) it will automatically be updated when new error codes are added without requiring that the developer remembers to do so (I doubt it would happen if anyone involved with H3 right now would do so, but in a couple of years a new contributor might not know and we might not remember if we don't explicitly see the sentinel definition in the Github diff view).

It could be made even more explicit by putting an inline multi-line comment above the H3_ERROR_SENTINEL stating something like:

/**
 * End of H3 Error Codes. Below is the sentinel value used for
 * iteration and sizing of the enum. Do not add error codes below it.
 **/

And if we want to be extra clever, the enum could be named H3_ERROR_LENGTH and then we still #define H3_ERROR_MAX (H3_ERROR_LENGTH - 1) below it so we don't have to have the subtraction in the code where the constant is used.