In this line of the prettytable-rs library, the format module is made public, exposing the use encode_unicode::Utf8Char within it.
As a result, the encode_unicode crate's impl FromIterator<Utf8Char> for Vec<u8> trait implementation becomes accessible. This accessibility leads to conflicts in code patterns like some_collection.iter().map(|x| x.into()).collect(), where x implements Into<u8>, due to the discovery of multiple FromIterator<T> for Vec<u8> implementations.
It seems unintended for the importing of prettytable-rs to inadvertently import the FromIterator implementation as well. Is there a particular reason for the format module being public? Would it be feasible to limit its scope to pub(crate) or take any other ways? I believe the crate should avoid exporting trait implementations unexpectedly.
In this line of the
prettytable-rslibrary, theformatmodule is made public, exposing theuse encode_unicode::Utf8Charwithin it.As a result, the
encode_unicodecrate'simpl FromIterator<Utf8Char> for Vec<u8>trait implementation becomes accessible. This accessibility leads to conflicts in code patterns likesome_collection.iter().map(|x| x.into()).collect(), whereximplementsInto<u8>, due to the discovery of multipleFromIterator<T> for Vec<u8>implementations.It seems unintended for the importing of
prettytable-rsto inadvertently import theFromIteratorimplementation as well. Is there a particular reason for theformatmodule being public? Would it be feasible to limit its scope topub(crate)or take any other ways? I believe the crate should avoid exporting trait implementations unexpectedly.