Micky774
commented
2 months ago Add a section somewhere making it clear that we are following the RFC.
IMO this is probably the most impactful change that could be made immediately. I failed to discover the reference at the bottom of the document, and that led to me making a series of not-quite-right interpretations 😅
Other than that, I think clarifying changelog entries a bit would help, e.g. for the v2023.12 API, one of the entries is:
fft.fft: require the input array to have a complex-valued floating-point data type and require that the output array have the same data type as the input array
The term "require" implies less freedom than the term "should" is meant to represent, and the beginning of the entry would perhaps be more precise as "clarify that the input array should have a complex..."
We use RFC 2119 for words like "should" and "must" in the standard. But many people are confused by this and think that "should" restrictions are actually "must" restrictions. This is most common for dtype restrictions, but it appears in other places in the standard as well.
We need to be clearer about this somehow. Some suggestions
Capitalize (as is the common convention) or bold these words (https://github.com/data-apis/array-api/issues/397)
Add a section somewhere making it clear that we are following the RFC. There is a link to the RFC at the bottom of https://data-apis.org/array-api/latest/purpose_and_scope.html but that's it. The RFC itself says:
The RFC also lists "required", "shall", "recommended", "may", and "optional". We should review our use of those terms to make sure they match the RFC.
We might be using "should" in places where we should be using "may" or "optional". From the RFC: SHOULD "means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course", but MAY "means that an item is truly optional". Things like data type restrictions are probably correct in using SHOULD, but things like indexing restrictions, like out-of-bounds slices" perhaps ought to use MAY, since the only reason they are limited is so the the standard can support libraries that can't implement them.
We should consider if there are other ways things could be made clearer, for instance, explicitly stating "other behavior is unspecified".