Document/Decide on `adapt(Backend, ...)` API

[vchuravy]

In #364 I added adapt(backend, x) as a natural extension for adapt, instead of having to use something like adapt(default_array_type(backend), x) which we don't currently have.

This was inspired by #353 and #297

As noted by @maleadt I didn't document it and it is a rather unofficial API that has lead users astray JuliaGPU/CUDA.jl#2459 (comment)

Ideally it would simply be adapt(::CUDABackend, x) = adapt(CuArray, x). I am not sure why I didn't use that definition before.

[jonas-schulze]

I like it. I don't know how I found out about, but to me it feels quite intuitive to allow adapt(::Backend, _).

[Hamiltonian-Action]

I would reckon that providing an API for querying the backend array type would still be useful irregardless of the syntactical sugar of adapt(::Backend, x), such as when passing them as template arguments for structures/functions.

[jonas-schulze]

I would reckon that providing an API for querying the backend array type would still be useful irregardless of the syntactical sugar of adapt(::Backend, x), such as when passing them as template arguments for structures/functions.

You could use typeof(allocate(::Backend, ...)) for that; see here. But if I got your intent wrong, let's continue in a different (new) issue.

[Hamiltonian-Action]

You could use typeof(allocate(::Backend, ...)) for that

I understand that there are many workarounds regarding the current limitations of the API, such as the one presented above -- heaven knows I have done some unspeakable kludge in order to get some implementations to work. However, I reckon that it is best to resolve the fundamental issue of enhancing the API coverage, with workarounds acting as a temporary stopgap.

[christiangnrd]

@vchuravy 👀

[vchuravy]

Yeah we should document and it and require it's implementation. Ideally with the adapt(::CUDABackend, x) = adapt(CuArray, x) definition.