| |
| ▲ | klabb3 3 days ago | parent [-] | | I meant in a general context (I know Go or Rust allows it in a decent way), not familiar enough with Haskell.. | | |
| ▲ | itishappy 3 days ago | parent [-] | | It's the same in Haskell as in Rust. Using the example from the article: struct A2(A);
impl BTrait for A2 {
fn random_number(&self) -> usize {
4 // chosen by fair dice roll, still!
}
}
In Haskell that translates to: newtype A2 a = A2 a
instance BTrait (A2 a) where
random_number _ = 4
Unfortunately, I also share GP's confusion. Can you share an example of what you mean by "type acrobatics with generics"? | | |
| ▲ | kreetx 3 days ago | parent [-] | | If it's the same, what is the blog posts problem then? | | |
| ▲ | itishappy 2 days ago | parent [-] | | It kinda sucks in both! If you want to interact with your newtypes, you need to either unwrap it or reimplement each typeclass/trait. Haskell does make this a bit nicer with deriving strategies, and Rust with macros, but it's a lot of boilerplate. The article had this to say about the example: > I’m sure it won’t take much to convince you; this is unsatisfying. It’s straightforward in our contrived example. In real world code, it is not always so straightforward to wrap a type. Even if it is, are we supposed to wrap every type for every trait implementation we might need? People love traits. That would be a stampede of new types. > Wrapper types aren’t free either. a_crate has no idea A2 exists. We’ll have to unwrap our A2 back into an A anytime we want to pass it to code in a_crate. Now we have to maintain all this boilerplate just to add our innocent implementation. | | |
| ▲ | kreetx 11 hours ago | parent | next [-] | | Does the Rust wrap/unwrap come with any runtime cost? I don't it sucks at all because implementing any type class (or trait, or interface), then if your new implementation is better (more efficient in time or memory) then you should propose to swap the old with the new at its original source location (i.e, create a merge request somewhere). If your implementation has a different output then you should consider whether this thing should actually be a type class at all (as it seems to be arbitrary). Or if your implementation is for a more specific case of the type, then making it a newtype is not only the practical thing to do, but it should actually be a new type. | |
| ▲ | filleduchaos 2 days ago | parent | prev [-] | | > If you want to interact with your newtypes, you need to either unwrap it or reimplement each typeclass/trait ...or you could just e.g. implement Deref in Rust? In my experience that solves almost all use cases (with the edge case being when something wants to take ownership of the wrapped value, at which point I don't see the problem with unwrapping) | | |
| ▲ | itishappy 2 days ago | parent [-] | | That gets us halfway there. It makes unwrapping easy, but you still need to remember to rewrap if you've implemented anything. use std::ops::Deref;
trait Test {
fn test(&self);
}
#[derive(Debug)]
struct Wrap<T>(T);
impl<T> Test for Wrap<T> {
fn test(&self) {
()
}
}
impl<T> Deref for Wrap<T> {
type Target = T;
fn deref(&self) -> &Self::Target {
&self.0
}
}
fn main() {
let thing1 = Wrap(3_i32);
let thing2 = Wrap(5_i32);
let sum = *thing1 + *thing2;
thing1.test();
thing2.test();
sum.test(); // error[E0599]: no method named `test` found for type `i32` in the current scope
}
Also using newtypes to reimplement methods on the base type is frowned upon. I believe that this is why #[derive(Deref)] isn't included in the standard library. See below (emphasis mine):> So, as a simple, first-order takeaway: if the wrapper is a trivial marker, then it can implement Deref. If the wrapper's entire purpose is to manage its inner type, without modifying the extant semantics of that type, it should implement Deref. If T behaves differently than Target when Target would compile with that usage, it shouldn't implement Deref. https://users.rust-lang.org/t/should-you-implement-deref-for... |
|
|
|
|
|
|
