Consider implment borshSerialize/de for (serde::)Serialize/de

[ailisp]

This gives a few benefits:

• issue like Failed to derive borsh ser/de in a recursive data structure #7 will work because serde gives handle recursive types support for free
• serde as defacto standard, those 3rd party container libraries, like IndexMap, usually have serde::deserialize implemented for it. And we cannot impl borshSerialize for all 3rd party containers. If user would like to impl borshSerialize for IndexMap, they cannot do because both the trait and the type is not in their crate. They have to wrap it to struct MyIndexMap(IndexMap) and impl borshSerialize for MyIndexMap
• issue like borsh#112 won't exist

Cons is with extra layer of Serde::Serialize trait, this may slowdown borsh, to be research

[frol]

Great proposal! I think it should be possible to implement it under a feature-flag, and also prefer native Borsh implementations before falling back to serde serializations.

[praveenperera]

This would be a great feature.

I was looking to replace Bincode with Borsh, but without being able to use serde_rename and having derives for UUID and other third party structs the friction is too high.

[matklad]

Hm, I think this is not the right thing to do. My understanding is that one (primary) design goal of borsh is canonicity/consistency:

Consistency means there is a bijective mapping between objects and their binary representations. There is no two binary representations that deserialize into the same object. This is extremely useful for applications that use binary representation to compute hash;

https://borsh.io

Serde is not canonical -- it can deserialize the same object from different representations (eg, order of key/values in a hashmap). We can't layer a canonical repr on top of a non-canonical one.

If the particular use-case does not require canonicity, then bincode should be used instead of borsh.

[frol]

I did not know that feature of serde. I am closing this issue since there are not action items