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
This is a trait intended to be implemented by "type constructor" types like OptionFamily, but notice it doesn't easily extend to other types. What if a type constructor has additional constraints?
We can see that MaybeFamily could never implement Family because of the generic type constraints, so we have to create a whole separate trait to accommodate for this. And we have to do this for every new complex type constraint, duplicating all the logic built on Family (e.g. maybe we built a Family>Functor>Applicative>Monad>... hierarchy and now we need to have CloneFamily>CloneFunctor>CloneApplicative>CloneMonad>... parallel hierarchy.)
Associated traits could be the perfect solution here, as a way to introduce restrictions to the GAT input parameter, and reuse the trait for all sorts of types:
traitFamily{traitBounds = ?Sized;// default-associated-type syntax for traits, // `?Sized` used to mean "no bounds" but could// use `()` unit trait if introduced as a concepttypeOf<T:Self::Bounds>;}structOptionFamily;implFamilyforOptionFamily{traitBounds = Sized;typeOf<T> = Option<T>;}structMaybeFamily;implFamilyforOptionFamily{traitBounds = Clone;typeOf<T:Clone> = Maybe<T>;}
This, together with non-lifetime binders like ... where for<T: Foo> Bar<T>: Baz<T>, ... would make GATs a whole lot more easy to work with, especially when expressing complex constraints.
In Haskell, this concept is used by libraries like rmonad to define restrictedRMonad typeclasses to enable datatypes such as Set to be made into monads.
The text was updated successfully, but these errors were encountered:
Currently, GATs are rather inflexible when it comes to their input parameters (especially if those are types) so you might have something like this:
This is a trait intended to be implemented by "type constructor" types like
OptionFamily
, but notice it doesn't easily extend to other types. What if a type constructor has additional constraints?We can see that
MaybeFamily
could never implementFamily
because of the generic type constraints, so we have to create a whole separate trait to accommodate for this. And we have to do this for every new complex type constraint, duplicating all the logic built onFamily
(e.g. maybe we built aFamily
>Functor
>Applicative
>Monad
>... hierarchy and now we need to haveCloneFamily
>CloneFunctor
>CloneApplicative
>CloneMonad
>... parallel hierarchy.)Associated traits could be the perfect solution here, as a way to introduce restrictions to the GAT input parameter, and reuse the trait for all sorts of types:
This, together with non-lifetime binders like
... where for<T: Foo> Bar<T>: Baz<T>, ...
would make GATs a whole lot more easy to work with, especially when expressing complex constraints.In Haskell, this concept is used by libraries like rmonad to define restricted
RMonad
typeclasses to enable datatypes such as Set to be made into monads.The text was updated successfully, but these errors were encountered: