kenba/opencl3

Use Rust types instead of cl-sys type aliases

Closed this issue · 2 comments

vmx commented

As #22 is a breaking change I'd like to bring up that I think opencl3 should always return Rust types where possible. For example instead of returning a cl_uint, returning a u32. Currently it's implicitly already the case that a cl_uint is a u32, and you can use it like that, but it is not clear from looking at the API documentation (only if you click on the actual type).

Many cl_* types are just just such type aliases in cl-sys. I propose change to those Rust types explicitly for the public opencl3 API.

kenba commented

Volker, I consider this to be different to issues #21 and #23.
They were about converting a C integer type representing a boolean to a rust bool, which is a logical change and may make the API more reliable, as demonstrated by PR #22.

The cl_* type aliases match the OpenCL API and make it easier for someone to understand from an OpenCL perspective. I can't see that it matters from a Rust perspective. As you point out, users can find out the underlying type in a modern IDE: in vscode I only have to hover over a type, not even click it!

Can you give an example where this change would make things easier for users of opencl3?

vmx commented

As you point out, users can find out the underlying type in a modern IDE: in vscode I only have to hover over a type, not even click it!

Can you give an example where this change would make things easier for users of opencl3?

Good points. I saw it from the Rust (not the OpenCL perspective) by someone reading the API docs. Given the cl_bool -> Rust bool change I thought it might be more consistent to have Rust types everywhere. Though practically it doesn't really make a difference. So your perspective makes sense to me, hence I'm closing this issue.