Should std feature imply rc feature and vice-versa?

[Fuuzetsu]

I'm not sure why these are separate. I think you can't enable rc without std and if you enable std then you also have Rc and Arc whether you like it or not.

Ideally rc would just get removed but enabling it as part of std seems like the second best thing.

[Fuuzetsu]

I guess serde also has rc feature, along with this comment:

# Opt into impls for Rc<T> and Arc<T>. Serializing and deserializing these types
# does not preserve identity and may result in multiple copies of the same data.
# Be sure that this is what you want before enabling this feature.
rc = []

[frol]

@Fuuzetsu rc is available from alloc crate, so std is not required to enable rc.

borsh-rs/borsh/src/lib.rs

Lines 139 to 140 in 2b1f6c9

	#[cfg(feature = "rc")]
	pub use alloc::{rc, sync};

[frol]

Though, we may indeed enable rc feature for std. @dj8yfo What do you think?

[dj8yfo]

it appears that serde added this feature for the sake of the warning in commentary about implications of behaviour on deserialization, thus (probably) forcing user to read the commentary before enabling it.

A logical way to continue is to add such commentaries to Cargo.toml and around BorshSerialize/BorshDeserialize impl as well and to default doc publish

[package.metadata.docs.rs]
features = ["derive", "unstable__schema"]  # add "rc" here