Would be nice to add to the agenda of the consortium meeting on Thursday. From the spec I cannot figure out if it is meant to be truly boolean or just truth/falsy (and if so, torch is not conformant)

from the spec I cannot figure out if it is meant to be truly boolean or just truth/falsy (and if so, torch is not conformant)

Ralf said:

+1 for accepting only boolean arrays. The note in the numpy.where docstring recommends doing that as the more correct option, and it's easy to do

And indeed this used to be in the standard, until it was (seemingly accidentally) lost with gh-116, as mentioned above.

And indeed this used to be in the standard, until it was (seemingly accidentally) lost with gh-116, as mentioned above.

That indeed seems to be completely accidental. I marked this for the 2024 milestone and backporting, will merge soon unless there are more comments, since it looks uncontroversial and caused by a minor editing hiccup only.

Since this should be backported, I believe we can go ahead and do that in this PR.

As the language uses should, not must, this allows array libraries to support truthy and falsy conditions for reasons of backward compat, and given that this was an editorial oversight, I'll go ahead and merge.

data-apis/array-api-strict#106 implements this in xp-strict

I don't care for the churn, but one day it may be nice spell things always clearly from either implementation or user perspective.

The user must pass a boolean (and the implemntation must support it). For the implementation you could suggest that it should reject non-bools if you are opinionated.
(Although, the may support more should be an implicit rule everywhere unless stated otherwise as a "must raise if ...".)