search

kenba / opencl3

A Rust implementation of the Khronos OpenCL 3.0 API.
Apache License 2.0
102 stars 13 forks source link

Use Rust types instead of cl-sys type aliases #23

Closed vmx closed 3 years ago

vmx commented 3 years ago

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 3 years ago

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 3 years ago

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.