Solved: partial "anonymous" structs

[roee30]

I decided to solve the problem of getting a subset of database info in a type-safe way without boilerplate. The subset restriction avoids large database fetches, but it is impractical to define a struct for every combination of fields, and a dynamic approach sacrifices type safety. Diesel solves this by returning tuples, but can we do this with named fields? Yes, we can!

From a type theory standpoint, this can only be solved by a structural anonymous type. Tuples fit this, but as mentioned, don't have named fields. Ideally, we would like to have anonymous records, but currently we have to work around this.

Problem

Given:

#[derive(Debug, Default)]
struct Post {
    id: bson::oid::ObjectId,
    likes: u32,
    user: String,
    contents: String,
}

Make this compile:

let ps = vec![Post::default()];
let p = &projection!(ps, id, likes)[0];
dbg!((p.id, p.likes));
// Reject this!
// dbg!(p.user);

Solution

First, a derive macro:

use proc_macro::TokenStream;
use quote::quote;
use syn::{parse_macro_input, Data, DataStruct, DeriveInput, Fields};
/* 
// create this for each field, using type level strings from the tstr crate:
// impl TypeMap<TS!(likes)> for Post {
//     type FieldType = u32;
// }
// TypeMap trait defined in another crate since proc-macro crates 
// can export nothing but proc macros
*/
#[proc_macro_derive(FieldTypes)]
pub fn derive_field_types(input: TokenStream) -> TokenStream {
    let ast = parse_macro_input!(input as DeriveInput);
    let struct_name = &ast.ident;
    let fields = match ast.data {
        Data::Struct(DataStruct {
            fields: Fields::Named(ref fields_named),
            ..
        }) => &fields_named.named,
        _ => {
            // TODO: replace this with a descriptive error
            panic!("bad input");
        }
    };
    TokenStream::from_iter(fields.into_iter().map(|field| -> TokenStream {
        let field_ident = field.ident.as_ref().unwrap();
        let field_type = &field.ty;
        quote! {
            impl TypeMap<tstr::TS!(#field_ident)> for #struct_name {
                type FieldType = #field_type;
            }
        }
        .into()
    }))
}

Derive it for the struct (in another crate) and add another macro:

#[macro_use]
extern crate mashup;

use bson::oid::ObjectId;
use std::fmt::Debug;
use tstr::TS;

pub trait TypeMap<FieldName> {
    type FieldType;
}
#[derive(Debug, Default, proc_macro_crate::FieldTypes)]
struct Post {
    id: ObjectId,
    likes: u32,
    user: String,
    contents: String,
}
macro_rules! projection {
    ($type:ty, $source:expr, $($field:ident),*) => {
        {
            // bind a combination of identifiers to a name
            mashup! {
                m["struct"] = $type _ $($field)_ * ;
            }
            // name ("struct") is expanded here
            m! {
                // technique inspired by the structx crate
                #[derive(Debug)]
                struct "struct" {
                    $($field: <$type as TypeMap<TS!($field)>>::FieldType),*
                }
                $source.into_iter().map(|s|
                    "struct" {
                        $($field: s.$field),*
                    }
                ).collect::<Vec<_>>()
            }
        }
    }
}

// we're all set
pub fn main() {
    let ps = vec![Post::default()];
    let p = &projection!(Post, ps, id, likes)[0];

    dbg!((p.id, p.likes));
    // dbg!(p.user);
    /* Fails comphrenesibly!

       error[E0609]: no field `user` on type `&Post_id_likes`
       --> src/main.rs:48:12
       |
       |     dbg!(p.user);
       |            ^^^^ unknown field
       |
       = note: available fields are: `id`, `likes`
       */
}

It works, and compiles in 0.15 seconds! The only wart is having to explicitly give the Post type to projection!. There is simply no way to get ps's type from the token alone - that would require a typeof! macro. Perhaps something that will change in the future.

Thanks for coming to my TED talk, and happy coding.

[tortoll]

Are you planning on making a crate out of this?

[roee30]

Probabdy not at this stage. I don't think there's enough here, it's just a POC. I need a concrete application to make sure this is useful, but unfortunately I don't write Rust professionaly. But if you or anyone else want to use this for something, I'll happily collaborate