The spec of `to_device()` method is missing

Here we mentioned there’s a to_device() method to enable data copy/movement across devices: https://github.com/data-apis/array-api/blob/09410675703ee275e6e5746db3aded0d37bc4b96/spec/design_topics/device_support.md#L48-L49 But we haven’t defined the signature and semantics yet.

[BvB93]

That makes sense to me. The “integer to stream” logic must be implemented anyway to support DLPack, so is not much of an extra burden. The actual union then becomes Union[int, _Stream] with _Stream: Any I guess?

Technically a Union is not the correct type here, as (with protocol arguments being contravariant) that would imply concrete implementation must, at minimum, have support for all union members. Instead, with int- and _Stream-support being optional, you’re in a similar situation to builtin protocols such as __abs__, wherein one of the types is a (somewhat constrained) free variable. Expressing the latter can be done with a typevar (e.g. ~T or ~StreamType), though arguably they don’t look quite as nice as unions.

Examples

from __future__ import annotation
from typing import Union, Protocol, Any, TypeVar

_Stream = Any
_T_contra = TypeVar("_T_contra", bound=Union[None, int, _Stream], contravariant=True)

# Concrete implementations must support all union-members
class SupportsToDevice1(Protocol):
    to_device(self, /, device, *, stream: int | None | _Stream = None): ...

# Concrete implementations must support one or more of the typevar bounds
class SupportsToDevice2(Protocol[_T_contra]):
    to_device(self, /, device, *, stream: None | _T_contra = None): ...

[rgommers]

Actually, let me ask a question about stream here: is using the DLPack-like integer the right choice here? I think libraries will either have no support for streams, or have custom objects. For DLPack there was little choice, because a custom class instance cannot work. However intra-library it could, similar to how Device itself works, or the dtype objects. Seems like that would be more natural.