You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
In this line of the
prettytable-rs
library, theformat
module is made public, exposing theuse encode_unicode::Utf8Char
within it.As a result, the
encode_unicode
crate'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()
, wherex
implementsInto<u8>
, due to the discovery of multipleFromIterator<T> for Vec<u8>
implementations.It seems unintended for the importing of
prettytable-rs
to inadvertently import theFromIterator
implementation as well. Is there a particular reason for theformat
module 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.The text was updated successfully, but these errors were encountered: