Open tailhook opened 7 years ago
A more elegant solution would be to use a trait instead of a wrapper
trait Hexable {
fn fmt_lower(&self, f: &mut fmt::Formatter) -> fmt::Result;
fn fmt_upper(&self, f: &mut fmt::Formatter) -> fmt::Result;
}
impl<H: Hexable> fmt::LowerHex for H {
// ...
}
(one might repurpose the ToHex
trait, but I think this could cause confusion, therefore I would opt for a separate trait)
I will make a PR for this 😊
Update: the above is blocked on #37 and/or specialization.
impl fmt::LowerHex for dyn ToHex {
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
write!(f, "{}", self.encode_hex())
}
}
error[E0038]: the trait `ToHex` cannot be made into an object
--> src/lib.rs:73:6
|
63 | pub trait ToHex {
| ----- this trait cannot be made into an object...
...
66 | fn encode_hex<T: iter::FromIterator<char>>(&self) -> T;
| ---------- ...because method `encode_hex` has generic type parameters
...
70 | fn encode_hex_upper<T: iter::FromIterator<char>>(&self) -> T;
| ---------------- ...because method `encode_hex_upper` has generic type parameters
...
73 | impl fmt::LowerHex for dyn ToHex {
| ^^^^^^^^^^^^^ the trait `ToHex` cannot be made into an object
|
= help: consider moving `encode_hex` to another trait
= help: consider moving `encode_hex_upper` to another trait
error[E0038]: the trait `ToHex` cannot be made into an object
--> src/lib.rs:74:12
|
63 | pub trait ToHex {
| ----- this trait cannot be made into an object...
...
66 | fn encode_hex<T: iter::FromIterator<char>>(&self) -> T;
| ---------- ...because method `encode_hex` has generic type parameters
...
70 | fn encode_hex_upper<T: iter::FromIterator<char>>(&self) -> T;
| ---------------- ...because method `encode_hex_upper` has generic type parameters
...
74 | fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
| ^^^^^ the trait `ToHex` cannot be made into an object
|
= help: consider moving `encode_hex` to another trait
= help: consider moving `encode_hex_upper` to another trait
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0038`.
error: could not compile `hex`.
To learn more, run the command again with --verbose.
and
impl<T: ToHex> fmt::LowerHex for T {
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
write!(f, "{}", self.encode_hex())
}
}
error[E0119]: conflicting implementations of trait `std::fmt::LowerHex` for type `&_`:
--> src/lib.rs:73:1
|
73 | impl<T: ToHex> fmt::LowerHex for T {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: conflicting implementation in crate `core`:
- impl<T> std::fmt::LowerHex for &T
where T: std::fmt::LowerHex, T: ?Sized;
error[E0210]: type parameter `T` must be used as the type parameter for some local type (e.g., `MyStruct<T>`)
--> src/lib.rs:73:6
|
73 | impl<T: ToHex> fmt::LowerHex for T {
| ^ type parameter `T` must be used as the type parameter for some local type
|
= note: implementing a foreign trait is only possible if at least one of the types for which is it implemented is local
= note: only traits defined in the current crate can be implemented for a type parameter
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0119, E0210.
For more information about an error, try `rustc --explain E0119`.
error: could not compile `hex`.
To learn more, run the command again with --verbose.
@Luro02 yes that would probably not work even with the specialization that is currently in the nightly compiler. That's because of orphan rules. This is why I've proposed the wrapper struct (a NewType). You can add a helper method for ToHex
trait to make that wrapper struct though.
That's because of orphan rules.
@tailhook the problems with the orphan rule seem to be two things:
https://github.com/Ixrec/rust-orphan-rules/blob/master/README.md#what-are-the-orphan-rules
The problem of overlapping implementations would be solved through specialization (the fmt::LowerHex
impl on our trait would be a default impl).
Specialization works through choosing the most specific implementation of a trait (e.g. impl Trait for Type
is more specific than impl Trait for Trait
).
A default implementation would be the least specific implementation, so any other impl will be preferred over this crates impl.
It might cause conflicts, if someone tries to import two different traits, which both have a default impl of the same trait, but in such a case the user should just cast the type to a trait object (type as &trait
).
So I think it will be possible to do this in the future 😊, but for now having a wrapper type would be useful too.
Hi,
It would be useful to be able to do something like:
This would allow hexlify things without creating temporary buffers.
What do you think?