(these are probably the most useful mappings, but not the only ones that make sense).

I guess this is probably the reason. For the first one in theory status can have multiple flags set, e.g. both GR_DOMAIN and GR_UNABLE (though the function could be changed to handle this), and for the second one there are cases where T_UNKNOWN is good, e.g. to check if a matrix with interval entries contains the zero matrix you can check gr_mat_is_zero(error_term, ctx) != T_FALSE.

For the first one in theory status can have multiple flags set, e.g. both GR_DOMAIN and GR_UNABLE (though the function could be changed to handle this),

Well, it already does — anything with GR_UNABLE set maps to T_UNKNOWN, which I think is usually what one wants (since one can only interpret GR_DOMAIN | GR_UNABLE as a domain error when one can be sure that the GR_DOMAIN flag wasn't set by a function called with incorrect input because of a previous unsupported operation).

and for the second one there are cases where T_UNKNOWN is good, e.g. to check if a matrix with interval entries contains the zero matrix you can check gr_mat_is_zero(error_term, ctx) != T_FALSE.

Sure, the idea is not to replace manually testing status flags or truth values, just to simplify some common cases.

Sure, it would make sense to have such conversions.

This may or may not be implemented in the future, but the set of return flags could conceivably be extended for more granularity. For example, one could have

GR_DOMAIN_NOT_INVERTIBLE, GR_DOMAIN_COMPLEX_RESULT, ...

GR_UNABLE_OVERFLOW, GR_UNABLE_INEXACT_COMPARISON, GR_UNABLE_NOT_IMPLEMENTED, ...

These would set the GR_DOMAIN / GR_UNABLE bits in addition to some extra flag bits.

So a forward-compatible logic for parsing status would be to first check status & GR_UNABLE, and in the else branch check for status & GR_DOMAIN.

On Sunday, 13 April 2025 Fredrik Johansson wrote:
This may or may not be implemented in the future, but the set of
return flags could conceivably be extended for more granularity.
Speaking of that, what do you think of reserving some bits from the
return flags for use by individual functions?
…

Do you have a specific use case in mind?

Yes and no. The other day I wanted to write a function that tried to do a certain computation using an incomplete algorithm and returned GR_UNABLE if that didn't work. Depending exactly why the computation failed (basically, when my function explicitly chose to return GR_UNABLE, as opposed to passing it on from some other function it called) I could still be sure that the value it wrote to its output variable made sense as a starting value for a second possible algorithm. I ended up structuring the code a bit differently, but I think it would have made sense to signal that to the caller by returning, say, GR_UNABLE | 0x10.