Partially Constructable Tuples?

[rljacobson]

I think the same machinery you use for HasFields and BuildField can work for tuples, possibly in two distinct ways:

1. A tuple with unique coorindate type: (v0, v1, v2, ...): (Type0, Type1, Type2, ...). Here the types play the role of the field names in structs and variant names in enums.
2. Use the coordinate position in the role of the field names in structs and variant names in enums.

The second feels like the more natural analog for tuples to me, but it seems to me you would want a mechanism like Builder::build_from::<n: usize>(value: TypeOfNthCoordinate).

I'm still learning the details of CGP, so some of these particulars might not be right, but I think the general idea should be clear. My questions are:

1. Is something like this (for tuples) already available in CGP? If not, is it planned?
2. The implementation I have in mind just follows what is described in the blog series. But I wonder if there is an easier way with tuples? I assume you have thought about this far more than I have.

My use case is implementing a compile-time isomorphism between tuples A and B that are the same up to permutation of coordinates, so that an instance of A can be constructed from an instance of B and vice versa. I also would like to build an instance of A from a tuple C the coordinates of which are a subset of the coordinates of A, with the remainder of the values supplied individually, say, or from one or more other tuples.

[rljacobson]

I spent a few hours trying to do some version of this myself. Accessors for any particular index are easy enough--in fact cgp has Index<N> for this purpose. But I couldn't figure out how to get the compiler to infer the reindexing.

I got a lot closer with the unique types idea, but ultimately the compiler would complain about ambiguity: I couldn't find a way to let the compiler know the types were unique.

It might be that the best you can do is give the fields names unrelated to their index and then treat them like a struct. That would at least give you the builder mechanisms.

[soareschen]

Hi @rljacobson, thanks for your exploration! Aside from partial records and extensible builders, CGP has another undocumented feature for HasFields, which is that you can use FromFields and ToFields to convert to/from the Fields type. Here is an example use:

#[derive(Clone, Debug, Eq, PartialEq, HasFields)]
pub struct Person {
    pub name: String,
    pub age: u8,
}

let name = "Alice".to_owned();

let person1 = Person { name: name.clone(), age: 32 };

// Product![ Field<symbol!("name"), String>, Field<symbol!("age"), u8> ]
let product = person1.clone().to_fields();
assert_eq!(product, product![name.clone().into(), 32.into()]);

// Product![ Field<symbol!("name"), &String>, Field<symbol!("age"), &u8> ]
let product_ref = person1.to_fields_ref();
assert_eq!(product_ref, product![(&name).into(), (&32).into()]);

let person2 = Person::from_fields(product);

assert_eq!(person1, person2);

The main difference between this and your approach is that the HasFields::Fields representation is a type-level list, which provides better support for type-level iteration. Also, each element is explicitly wrapped in a Field<Tag, Value> type, which is really just a wrapper around a value with the field name used as the phantom Tag type.

If you still want to use regular N-tuples with ToFields and FromFields, there are ways you can implement conversion between the two by flattening the type-level list and removing the Field wrapper. I also thought of providing automatic conversion between type-level lists and N-tuples up to 32 or 64 elements. Note that this conversion need to be explicitly generated, as we cannot inductively implement it without support for variadic tuples in Rust.

[rljacobson]

Thank you for the detailed reply!

When I was playing around with it I tried using frunk's implementation, which has an HList type that is like you describe. I was a little surprised there wasn't already a built-in conversion for tuples--at least not that I could see, but I've been known to miss the obvious. It's easy enough to write your own, though.

I think people generally want these "magic" tools for tuples specifically because they don't have control over whatever is forcing the tuple type on them for some reason.

[soareschen]

Yeah, unfortunately there is no automatic conversion available right now. I have discussed about this on the Reddit discussion on variadic generics, but it may take a while for it to be implemented.

As an alternative, I am thinking of generating something like follows inside a proc macro, so that we can automatically convert between the representations for N-tuples up to 32 or 64:

impl<T1, T2> From<(T1, T2)> for Cons<T1, Cons<T2, Nil>> {
    fn from((v1, v2): (T1, T2)) -> Self {
        Cons(v1, Cons(v2, Nil))
    }
}

impl<T1, T2> Into<(T1, T2)> for Cons<T1, Cons<T2, Nil>> {
    fn into(self) -> (T1, T2) {
        let Cons(v1, Cons(v2, Nil)) = self;
        (v1, v2)
    }
}

impl<T1, T2, T3> From<(T1, T2, T3)> for Cons<T1, Cons<T2, Cons<T3, Nil>>> {
    fn from((v1, v2, v3): (T1, T2, T3)) -> Self {
        Cons(v1, Cons(v2, Cons(v3, Nil)))
    }
}

impl<T1, T2, T3> Into<(T1, T2, T3)> for Cons<T1, Cons<T2, Cons<T3, Nil>>> {
    fn into(self) -> (T1, T2, T3) {
        let Cons(v1, Cons(v2, Cons(v3, Nil))) = self;
        (v1, v2, v3)
    }
}

[rljacobson]

If anyone is curious how you might implement the tuple → struct → tuple strategy for distinct named types (my use case), here's one way. This lets you convert a tuple to another tuple with the same types but different order. The trait solver computes the reordering via the builder mechanism of CGP.

use cgp::core::field::CanBuildFrom; // Not in the prelude.
use cgp::prelude::*;
use paste::paste;

macro_rules! new_tuple {
    ($name:ident, ($($param:ident),+ )) => {
      paste::paste!{
        #[derive(Debug, Copy, Clone, HasFields, BuildField)]
        struct $name {
          $(pub [<_ $param:lower>] : $param,)+
        }

        impl From<($($param),+)> for $name {
          fn from(value: ($($param),+)) -> Self {
            let ( $( [<_ $param:lower>],)+ ) = value;

            Self{
              $( [<_ $param:lower>],)+
            }
          }
        }

        impl From<$name> for ($($param),+) {
          fn from(value: $name) -> Self {
            ($( value.[<_ $param:lower>],)+)
          }
        }
      }
    };
}

new_tuple!(Tuple_1_2, (Type1, Type2) );
new_tuple!(Tuple_2_1, (Type2, Type1) );

#[test]
fn test_new_tuple() {
  let unordered = (Type2, Type1);
  let unordered_tuple = Tuple_2_1::from(unordered);
  let ordered_tuple = Tuple_1_2::builder().build_from(unordered_tuple).finalize_build();
  let ordered = ordered_tuple.into(); // Type inferred via assert.

  assert_eq!((Type1, Type2), ordered);
}

You could modify this in various ways, of course, but this is the basic idea. You can do this for any set of distinct types if you use the rustc_const_unstable feature, as that would give you a mechanism to synthesize the field names, which I do in a simplistic way with paste!.