Add first impl

[killercup]

Sorry, I couldn't stop myself! 😄

Best review by reading the commits one after another.

[colin-kiegel]

wow, that was fast - I will need some time for that. :-)

[killercup]

I think it makes sense to land a pretty basic version and add stuff one feature at a time. This has a few tests (but not nearly enough) and just implements setters.

I need to investigate how to best generate getter names. I really want this to generate idiomatic Rust, so getters names would be prefixed with get_, e.g. get_foo() and get_foo_bar().

If I read rust-lang/rust#29599 correctly, it's not possible to generate ident on stable. If we were to do getters on nightly only, interpolate_idents might be helpful (usage example).

A more creative solution for stable might be creating a single get(&self) -> new_sub_module::Getter method, where Getter is a newtype that implements methods to get each of the struct fields, so you can do x.get().foo().

[killercup]

Btw, feel free to enable travis and configure it some more (to render docs and stuff) – I just added a basic file so we don't forget about it :)

[colin-kiegel]

That's ok for me. I think it's not worth the effort to try to support them - because some kind of implicit naming is needed after all. So let's just require explicitness here. :-)

[colin-kiegel]

looks awesome. :-)

[colin-kiegel]

PS: added travis.yml in master - please feel free to finetune it. I just copied a template from another project...

• E.g. coveralls probably does not make sense for a macro crate.
• nightly build fails on travis #6

[killercup]

Let me just rebase this on master to make it mergeable again.

[killercup]

I added TRAVIS_CARGO_NIGHTLY_FEATURE="", by the way, so this actually has a green build now :)

coveralls probably does not make sense for a macro crate.

I'm not sure. I might be clever enough to tell us that we are not testing all the code the macro is generating. Let's wait and see what it says.

[colin-kiegel]

Yippieh :-)

Btw: Do you prefer a squashed merge or the usual one in these cases?

[killercup]

I prefer regular merges with all commits/history intact, since I try to build up features and it's nice to see how something was put together. When there are too many small fixes in response to feedback I'm cool with squashing those, though.