Oops, was supposed to be a Draft. It looks like there's no way to make a PR into a Draft once it's non-Draft?

An alternative approach I'm tinkering with is to add a method to the Vasi trait, and access the fields by name in the body instead of trying to name the (possibly generic) types of the fields.

It looks like this could actually work but requires additional complexity to deal with unnamed fields, enum variants, union fields (which need unsafe access), ...

Anyway the idea is to change the vasi trait declaration to:

pub unsafe trait VirtualAddressSpaceIndependent {
    /// Used by the derive macro to validate that fields are Vasi.
    fn is_vasi(&self) {}
}

and then in the macro, for MyWrapper above generate something like:

impl <T> VirtualAddressSpaceIndependent for MyWrapper<T> where T: VirtualAddressSpaceIndependent {
  fn is_vasi(&self) {
    VirtualAddressSpaceIndependent::is_vasi(&self.val);
  }
}

@stevenengler if you get a chance to look at this, maybe you have a better idea how to do this?

I'm still not sure I understand completely, but could you do something more like the Copy derive where it's a compile-time failure if a non-generic field is not Copy, but then is derived conditionally for generic fields?

So something like:

#[derive(VirtualAddressSpaceIndependent)]
struct MyWrapper<T, K> {
    foo: Option<T>,
    bar: u32,
    asdf: K
}

becomes:

struct MyWrapper<T, K> {
    foo: Option<T>,
    bar: u32,
    asdf: K
}

assert_impl_all!(u32: vasi::VirtualAddressSpaceIndependent);

unsafe impl<T, K> VirtualAddressSpaceIndependent for MyWrapper<T, K>
where
    Option<T>: VirtualAddressSpaceIndependent,
    K: VirtualAddressSpaceIndependent,
{}

My understanding is that the derive macro for Copy is conditional on the generic type parameters being Copy, not the field types being Copy

According to https://stegosaurusdormant.com/understanding-derive-clone/#do-we-have-to-inspect-the-fields this is because making the constraints on the field types can leak private types into the public interface, which results in compilation errors. Maybe we could live with that limitation, though.

Ah okay, I wondered then what happens if T were Copy but Wrapper<T> were !Copy. It seems like there's maybe some compiler magic that doesn't ever let this happen, so a better example is probably Clone. And your link shows why that would fail (the field access in the derived clone() method will try to call clone() on the field, but it not compile since Wrapper<T> doesn't always implement Clone).

Here's another idea to avoid requiring a method in the trait. It still needs to access each field though:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=712fb56f0c303a52111503c4d0f34484

Or maybe one of these so that you don't need to access each field:

https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=3a0c36ad9b478208d194d6762dab095a
https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=b6fc455b03d053012f960ed2877f1b19

I think we're miscommunicating. My understanding (and I think this matches what you're saying) is that e.g. for:

#[derive(Copy, Clone)]
struct MyStruct<T> {
    _x: T,
}

MyStruct is conditionally Copy and Clone. e.g. MyStruct<Box<T>> can be constructed, but won't be Copy since Box is never Copy.

OTOH for a struct definition is

#[derive(Copy, Clone)]
struct MyStruct<T> {
    _x: Box<T>,
}

then there will be a compilation failure since _x isn't Copy even if T is.

i.e. this is different from your earlier example that would emit where Option<T>: VirtualAddressSpaceIndependent,; in particular that approach has the problem of exposing the field types in the public interface, and failing to compile if those types are private.

Anyways, I think I've gotten something working, and the ideas in your gist were definitely helpful - particularly using a trait const instead of a trait method seems a little nicer, and facilitates ensuring the code is never called at runtime (and probably dropped from the final binary).

It's currently checking the field values, though I may revisit your idea that uses the types instead. I'll take another look at that and clean up a bit before marking it for review.

I think this is ready now! Thanks for the help and ideas!