6 ms·

The newtype pattern is a special case of type composition which is incredibly useful, has low complexity, and if done right almost no boilerplate overhead. It's

by klabb3 2y ago

The newtype pattern is a special case of type composition which is incredibly useful, has low complexity, and if done right almost no boilerplate overhead. It's much dumber and easier to reason about than type-acrobatics with generics, imo.

kreetx 2y ago
Do you mean `Generically`[1]? I've only ever vaguely seen its use - perhaps it can do something a `newtype` can't (or can, but with more boilerplate)? But don't have any first-hand experience currently to comment. [1] https://hackage.haskell.org/package/base/docs/GHC-Generics.html#t:Generically https://hackage.haskell.org/package/base/docs/GHC-Generics.h...
- klabb3 2y ago
  I meant in a general context (I know Go or Rust allows it in a decent way), not familiar enough with Haskell..
  - itishappy 2y ago
    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 2y ago
      If it's the same, what is the blog posts problem then?
      - itishappy 2y ago
        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.
        filleduchaos 2y ago
        > 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 2y ago
        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-newtype-wrappers/117204/13 https://users.rust-lang.org/t/should-you-implement-deref-for...

by klabb3 2y ago

kreetx 2y ago

Do you mean `Generically`[1]? I've only ever vaguely seen its use - perhaps it can do something a `newtype` can't (or can, but with more boilerplate)? But don't have any first-hand experience currently to comment. [1] https://hackage.haskell.org/package/base/docs/GHC-Generics.html#t:Generically https://hackage.haskell.org/package/base/docs/GHC-Generics.h...

klabb3 2y ago
I meant in a general context (I know Go or Rust allows it in a decent way), not familiar enough with Haskell..
- itishappy 2y ago
  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 2y ago
    If it's the same, what is the blog posts problem then?
    - itishappy 2y ago
      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.
      - filleduchaos 2y ago
        > 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 2y ago
        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-newtype-wrappers/117204/13 https://users.rust-lang.org/t/should-you-implement-deref-for...