Determine Struct to use in Macro based off of a $ty passed in

I’ve got a macro that I’ve written that is doing everything I’d like except I’d like to make it work without requiring a type parameter. In this future case I plan on using a procedural macro to define a struct that takes no type parameters but mirrors the struct passed to the procedural macro. I’d like to avoid the type parameter because my understanding is that it will limit de-/serializability.

#[macro_export]
macro_rules! partial {
    ( $type:ty { $( $prop:ident: $value:expr ),* } ) => {
        {
            type T = Partial<$type>;
            T
            {
                $(
                    $prop: PartialProperty::UserDefinedValue($value),
                )*
                ..T::default()
            }
        }
    };
}

I know these macros are operating with ASTs and so I can’t simply do something like this, but hopefully it gets the idea across of what I am looking to do.

#[macro_export]
macro_rules! partial {
    ( $type:ty { $( $prop:ident: $value:expr ),* } ) => {
        {
            Partial$type
            {
                $(
                    $prop: PartialProperty::UserDefinedValue($value),
                )*
                ..Partial$type::default()
            }
        }
    };
}

Where the idea is that the type can be derived by a concatenation of 'Partial' + ${original_type_name_here}.

Is there a way I would be able to determine what struct I should be attempting to instantiate based off of the struct type passed in?

Are you matching $type with :ty because you need to? Are any of the types more complicated than an identifier? Or do you have things like Type<T> or etc? A general solution for parsing types in macro_rules without turning them into an AST node is nearly impossible.

If it’s just an identifier… well, even then you’ll still have trouble. You can’t concatenate identifiers in macro_rules!; this will require a procedural macro.

…well… actually…

I have not used it myself, but @dtolnay has a crate called mashup, which wraps up that one key piece of identifier-concatenating functionality you need so that you don’t need to write your own proc_macro. It does have some funky limitations to be aware of, but it’s usable on stable. Best of luck!

Awesome! That lead me to concat_idents which I was able to use successfully since I don’t need more than that and am not worried about stable support!

Thank you for the help!