Spell out where views are allowed

コピー、ビュー、ミューテーションに関するリンク先のセクションから始め、特に sum の例に注目して array_api_compat PR 298 を確認してください。ビューを生成する一覧中の関数を、issue で取り上げられている他の操作と比較し、ビューをいつ許可するかについて、明示的で合意された範囲を文書化してください。標準がこれらのケースを明確に解決していれば完了です。

In https://data-apis.org/array-api/latest/design_topics/copies_views_and_mutation.html, the Standard says

Array API consumers are strongly advised to avoid any mutating operations when an array object may [...] be a “view” [...] It is not always clear, however, when a library will return a view and when it will return a copy. This standard does not attempt to specify this—libraries may do either.

The above is fine after __getitem__ , asarray(..., copy=None), astype(..., copy=False), and similar functions that are explicitly explained by the standard to potentially return views.

However, there are a few corner cases where views could be possible but a normal user is very unlikely to think about them.
I just stumbled on one in https://github.com/data-apis/array-api-compat/pull/298, where array_api_compat.torch.sum(x, dtype=x.dtype, axis=()) was accidentally returning x instead of a copy of it.

There are a few more cases where a library could try to be smart; for example

• search functions (min, max, other?) could return a view to the minimum/maximum point
• replacement functions (minimum, maximum, clip, where) could return one of the input arrays when there is nothing to do
• same for arithmetic functions (__add__ / __sub__ vs. 0, __mul__ / __div__ vs. 1, etc.)
• same for sort functions when they realise the input is already sorted
• possibly more

In real life, I expect end users to assume that the above functions will always return a copy.
I think the standard should spell this out, limiting the possibily of views to an explicit list of allowed functions:

• __getitem__
• asarray
• astype
• __dlpack__
• from_dlpack
• reshape
• broacast_to
• broadcast_arrays
• ...more?