kulst commented on PR #627: URL: https://github.com/apache/celix/pull/627#issuecomment-2038429466
Hi, thank you for the detailed explanations! I aswell think that Rust would really benefit Celix. The exclusive use of safe Rust guarantees that memory and type conversion errors as well as undefined behavior are excluded - through compile time and runtime checks. This should also be the goal for the Rust API of Celix. If any of these errors occur to the user of the API when using safe Rust only, it should be considered a bug in the Rust API or Celix. However, whether it is possible to offer a Celix API that consists exclusively of safe Rust is still unclear to me. I think the existing C API is a great starting point for now, as Rust interopperates usually well with C. As you already showed :) For now I would start with making myself more familiar with Celix. I was already able to develop a basic understanding of most of the concepts of Celix. But I definitely need to further enhance this. I will start by installing Celix and trying to get your Rust examples to work, lets see if I can also make it work with the latest version 2.4. The next step would be to get a better understanding of the invariants that need to be upheld when using the C API. I saw, that a lot of these are already documented, but I assume there are more and maybe also implicit ones. When this is done, the Rust API can be designed. Of course I want to leverage the Rust type system to make sure that the invariants of the C API are upheld. Your POC is also a great starting point. For now I think this is already a lot to do. Let's see where this leads me. :) In any case, an ASF Contributor Agreement will not be an obstacle. Topics I stumbled upon but which I have put in my backlog for now: **Allocation:** by default allocating and deallocating on different sides of the ffi might lead to undefined behaviour. There are several possible solutions to this 1. implementing a (global) allocator in Rust that delegates to the Celix allocator 2. making sure that both happens on the same side of the FFI by the Rust type system **Type conversion:** There are various types in the C API that are similar to Rust types but can not be used as smoothly without further adjustments on the Rust side. For example the `array_list` type is similar to a vector (with some additions). 1. So one solution to use such a type smoothly in Rust, you basically would have to reimplement the interface of the `std::vec` type. 2. Another solution is to just copy the elements to the corresponding type before/after passing the ffi boundary. This might be inefficient however. 3. A third solution might only be possible when allocation and deallocation happen on the same side of the ffi boundary. I think it could then be possible to create a `std::vec` from the internals of an `array_list` without another allocation just by using the pointer, the size and the capacity an `array_list` already provides. Together with the additions of an `array_list` this could be packaged in a simple wrapper type. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@celix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
