Remove string cow

[therealprof]

This is mostly an ergonomics change. Getting rid of Cow for strings removes a substantial amount of boilerplate and brings us a tiny step closer to being able to use quick-protobuf with no_std.

I've converted a project to use the improvement as an experiment if you'd like to take a look: https://github.com/axiros/rusp/tree/no-cow-string-experiment

[therealprof]

@tafia Any feedback on these kind of changes?

[tafia]

Sorry for the late answer. Looks really nice but I need to find some time to test it properly. I am sorry it is taking so long but I don't have much time at the moment. I'll try to have a look this week-end
Thank you very much!

[tafia]

So I am looking at the PR (thanks again!). I agree that it simplifies things quite a lot but unless I'm missing something I don't understand how people are supposed to use it in practice,

I mean using &str, works well when we need to deserialize structs but not so well when people just want to Serialize their own structs (with Strings for which they don't want to bother having a different owner). With the Cow, there is a possibility of using Cow<'static>/Cow::Owned even if it is far from being super convenient.

I would be happy to have a special flag to enable this type of scenario (with some comment explaining the rationale).

Also for #[no_std] i believe that with the last rust release (stabilization of the alloc crate) we should be able to handle String/Vec eventually (I can't work on it just yet and I am not very knowledgeable with no_std).

[therealprof]

I mean using &str, works well when we need to deserialize structs but not so well when people just want to Serialize their own structs (with Strings for which they don't want to bother having a different owner).

I'm not sure I understand what you mean by serialisation. Generate protobuf messages from Rust? I'm doing that right here: https://github.com/axiros/rusp/blob/no-cow-string-experiment/src/usp_generator.rs#L372 and the data comes in from the CLI via a Option which can be as easily turning into a &str as it is turning into a Cow::Borrowed, done e.g. https://github.com/axiros/rusp/blob/no-cow-string-experiment/src/main.rs#L316 .

Also for #[no_std] i believe that with the last rust release (stabilization of the alloc crate) we should be able to handle String/Vec eventually (I can't work on it just yet and I am not very knowledgeable with no_std).

It's not that easy, even if there was a compatible allocator (which there isn't), the available heap will be of a static rather limited size so I'd expect tossing strings around will still need careful consideration and in many if not most cases be a no-go. Reliability is key in embedded, so one would definitely want to avoid code that might panic due to out-of-memory situations and not even run on some configurations at all.

[tafia]

Sorry if I wasn't clear.

In your example, you don't take ownership of version, to_id, from_id and msg (assuming all fields are not statically defined). Sometimes you want to have full or partial ownership of your fields (to release a resource, send the struct to another thread etc ...).

Correct me if i'm wrong but your variant works well for situations where the messages are just temporary struct used to import / export data into protobuf, not for more general purpose situations.

Regarding #no_std you are probably right.

Again I would be happy to provide this no-cow version behind a flag.

[therealprof]

In your example, you don't take ownership of version, to_id, from_id and msg (assuming all fields are not statically defined). Sometimes you want to have full or partial ownership of your fields (to release a resource, send the struct to another thread etc ...).

Uhm, the caller of the function has ownership of the value, cf. https://github.com/axiros/rusp/blob/no-cow-string-experiment/src/main.rs#L316. The reason I'm taking a &str instead of String is probably the same as to why you're using Cow in the first place: So I don't have to clone values all over the map. (And of course because I live in a no_std world we try to avoid heap-only datatypes as much as possible)

I'm actually not quite sure why you're even using Cow in the first place; this is a smart pointer type meant to be used for data you might have to mutate which will hopefully never happen for protobuf marshalling. 😅A more appropriate type for read-only shared data would be Rc or Arc (for multithreading).

[tafia]

Also somehow linked #143

[nerdrew]

Having the ability to change the string values in messages helps my app quite a bit. I'm not sure how I'd use quick-protobuf if all the messages were tied to the lifetime where they were created. Note: I'm using tokio + futures quite a bit, so I think the messages must have a 'static lifetime.

[therealprof]

@tafia To be honest I have no idea what the advantage of using rental in this context would be.

[therealprof]

@nerdrew I'm using the actix framework and haven't encountered any troubles yet but I can run some more exhaustive tests.

[therealprof]

Conflicted by #158