#Using GAT to be generic over generic type ?

23 messages · Page 1 of 1 (latest)

pseudo galleon
#

You need to choose a specific type to be the Bar type. That is, given the type BarSGen, the type T, and the type F, there must exist exactly one type that is referred to by <BarSGen<T> as TBar>::Bar<F>

#

What are you trying to accomplish? What are these traits for?

#

-xy

hollow stratusBOT
#

Hi! We’d like to help you with your current problem, but we have to know more about its surrounding context. What is the goal that you are trying to accomplish, as a whole? Not only can more information help fixing the problem better, sometimes it turns out that the best solution to accomplish your goal is something else entirely. This is known as an X-Y-problem. See: https://xyproblem.info/

dawn kestrel
#

Ignoring whether the compiler will accept it, what would you like the Bar<T> type to be set to? I can read T where T: TFoo<Foo = T>, but I have no idea what you're trying to mean with that

#

That you want to set an infinite family of possible associated types: every T that is TFoo<Foo = T>?

#

We have a tool for that, it's called generics

#

You can have a generic on a trait and then write an impl for such an infinite family of possible types to fill in the generic

#

(of course, generics can't be themselves generics, because no HKTs, so you would have to look into emulating HKTs with GATs)

#

But aside from this, I strongly urge you to answer Helix's questions. What are you even trying to do, and why?

dawn kestrel
#

a generic type T
Good to see that you managed to make it work, but here I'd have to ask you which generic

#

You don't declare generics there, you declare them next to the impl keyword.

#

I mean that I am extremely confused by what you're trying to convey with that syntax

#

type Bar<F: Debug> = T where T: TFoo<Foo = F> is not valid syntax, and also it does not make any sense semantically

#

My best understanding of it would be that you're trying to say that Bar<F> for a given F isn't one type, it's infinitely many types

#

Which is just Not How Associated Types Work

#

An associated type is one type. A generic associated type is still only one type, it's just that which type it is depends on the generic.

#

The use case of associated types would be letting someone say that, for example, type Collection<T> = Vec<T>;

#

The idea being that if I write Foo::Collection<u32>, that's enough to fully identify which type it is

#

(it's Vec<u32>, in this example)

#

What you're trying to achieve here is a system where Owo::TBar<Uwu> doesn't give you a type. it gives you an infinite collection of possible T types

#

That's usually what generics are for, broadly speaking

#

(but also, generics can't be themselves generic, there's no trait Owo<Collection<_>>, which makes this harder to express through them. The search keyword for this is "hkts", or "hkt emulation")