Implement `Type` for commonly used Rust types from external crates

[zeenix]

trafficstars

First candidates would be url::Url and uuid::Uuid. Some of them are here.

[zeenix]

In GitLab by @bilelmoussaoui on Oct 24, 2020, 04:19

while not completely related, it would be nice to have Type implemented for std::ffi::CString as well. I had a bunch of null terminated strings on some dbus calls that I had to add my own wrapper for now

[zeenix]

while not completely related, it would be nice to have Type implemented for std::ffi::CString as well.

Right, see also this TODO comment. Since you already implemented Type for it, perhaps it'd be a trivial contribution?

I had a bunch of null terminated strings on some dbus calls that I had to add my own wrapper for now

All D-Bus strings are null-terminated and our (de)serializer takes care of that for you so I'm a bit curious as to why you needed to take care of null termination yourself.:thinking:

[zeenix]

In GitLab by @bilelmoussaoui on Oct 24, 2020, 21:12

I had a bunch of portals methods calls that took a null terminated string (while others didn't?) and I was a broken thing until I added a NString, that wraps CString & implements Type for it

[zeenix]

I had a bunch of portals methods calls that took a null terminated string (while others didn't?)

That seems like a bug in the portal implementation then. If the type of the data is s, it must be null-terminated cause otherwise you're breaking the spec. It says:

UTF-8 string (must be valid UTF-8). Must be nul terminated and contain no other nul bytes.

but that's on the D-Bus level. The Rust's String and str types are not null-terminated so zvariant adds the null-byte during serialization and removes it during deserialization for you. In any case, user shouldn't have to care.