Hello everyone, I am currently working on a Rust Wrapper for KConfig KDE Framework (https://invent.kde.org/oreki/kconfig-rs) as part of Season of KDE 2022. For the most part, I have made the wrapping methods one-to-one with the C++ API. So they use the same arguments and return types as their C++ counterparts.
However, during this process, I have come across some methods where I can change the API in the Rust side to take better advantage of the Rust type system. An example of this situation: `QString readGenericName () const` method of KDesktopFile (https://api.kde.org/frameworks/kconfig/html/classKDesktopFile.html#aaf263b79cce3125c9e6e52428e05c524). If I am doing a one-to-one wrapping, the Rust function definition would look something like this: `fn read_generic_name(&self) -> QString` By default, this function returns `QString()` in case the key is not present in the `.desktop` file. According to me, a better definition for this function will be: `fn read_generic_name(&self) -> Option<QString>` The function will return `None` if the key is not present in this case. There are more parts of KConfig similar to this. However, I wanted to know other people's opinions on how faithful should the Wrapper be to the original library in general. Is it better to have the same signatures as the underlying library as far as possible? Or is it better to break away from the library API when the Language allows having a stricter and 'misuse-resistant' API? Here is a great article about Type-Driven development that goes into much more depth about using Rust Type System to its fullest: https://duesee.dev/p/type-driven-development/ Yours Sincerely, Ayush Singh
