systemdata and saveload_systemdata macros

Description

I've created two (procedural) macros to write system data structs more concisely. I'm opening this "feature request" to 1. share them, 2. offer them as contributions or at least inspirations. The implementations currently live in https://github.com/abesto/rktrl/blob/master/rktrl_macros/src/lib.rs.

Motivation

`systemdata`

Minimize boilerplate
Standardize naming of fields, but allow overriding

Example usage

systemdata!(SpawnerSystemData(
    entities,
    write_storage(
        (serialize_me: SimpleMarker<SerializeMe>),
        AreaOfEffect,
        BlocksTile,
        [...]
        Viewshed,
    ),
    write((serialize_me_alloc: SimpleMarkerAllocator<SerializeMe>)),
    write_expect((rng: RandomNumberGenerator)),
    read_expect((spawn_requests: EventChannel<SpawnRequest>))
));

Generates roughly:

#[derive(SystemData)]
struct SpawnerSystemData<'a> {
    entities: Entities<'a>,

    serialize_me: WriteStorage<SimpleMarker<SerializeMe>, 'a>,
    area_of_effects: WriteStorage<AreaOfEffect, 'a>,
    [...]

    serialize_me_alloc: Write<SimpleMarkerAllocator<SerializeMe>, 'a>,
    [...]
}

`saveload_systemdata`

Minimize boilerplate
Work around the size limit (16) of tuples supported for saving (https://github.com/amethyst/specs/issues/414)
Prevent mistakes where the order of components when saving and loading is mismatched

The implementation solves the 16 tuple size limit by chunking components into 16-sized tuples, so that actual saving would iterate over 16-tuples and save those one by one.

Example:

saveload_system_data!(
    components(
        AreaOfEffect,
        BlocksTile,
    )
    resources(Map, GameLog)
);

Generates roughly:

#[derive(SystemData)]
struct SaveSystemData<'a> {
    entities: Entities<'a>,
    components: ((ReadStorage<AreaOfEffect, 'a>, ReadStorage<BlocksTile, 'a>),),
    map: ReadExpect<Map, 'a>,
    game_log: ReadExpect<GameLog, 'a>
}

#[derive(SystemData)]
struct LoadSystemData<'a> {
    entities: Entities<'a>,
    components: ((WriteStorage<AreaOfEffect, 'a>, WriteStorage<BlocksTile, 'a>),),
    map: Write<Map, 'a>,
    game_log: Write<GameLog, 'a>
}

Drawbacks

More magic than is usual for specs
Error messages are sometimes hard to understand when macro usage is messed up
Builds on top of current specs_derive instead of integrating with it deeply

Unresolved questions

I'm using this in my hobby project happily, but have zero experience with production-ready macros. That's where I expect most of the problems (unknown to me currently) to creep in. I guess there's also bikeshedding to be done around the syntax.

I'd be happy to "formally" contribute these macros as a PR if it makes sense, and to put in some work iterating on them based on feedback.

amethyst / specs