Changing Original Library API when writing Wrappers

[Ayush Singh]

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