Skip to content

Ignore a subset of type parameters, map a certain type parameter #2

Description

@MxmUrw

Hey, first of all, thanks a lot for writing this! This is going to save writing some tedious code for sure!

I have two (related) ideas for features that would be pretty helpful in my case:

Ignore certain type parameters when generating the mapping code for a given struct

Let's say I have

struct T<A: TypeCarrier, B, C> {
  a_0: A::Type0,
  a_1: A::Type1,
  a_2: A::Type2,
  b: B,
  C: C
}

then currently the generation fails since there's a something going on with associated types. But let's say I don't care about mapping over A, it would be very cool if I had the option to control which type arguments are taken into account while generating the map function, and which can stay constant. So in this case I would for example have an attribute saying #[generate_map_for(B,C)] and then the mapping function would be effectively of the following type:

fn map<A: TypeCarrier, B0, C0, B1, C1>(self: T<A, B0, C0>, f: impl Fn(B0) -> B1, g: impl Fn(C0) -> C1) -> T<A, B1, C1> {
  ...
}

Have specialized map implementations that map only a single parameter, and apply identity on all others

Let's say I have a struct S<A,B,C> and I do want to sometimes map over all type parameters, but sometimes I only want to change the third type argument for example. So it would be pretty handy to (in addition to generating map()) also generate specialized map_a, map_b and map_c functions which keep all type arguments constant except one.

I might look into implementing this myself and submitting as PR, but it would be nice to have some pointers as to how easily feasible this would be, and where I start looking. I figure you'd have a good idea what this change would involve.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions