Add from support for the setters

[roblabla]

This PR adds the ability for setters to take a type to convert back into an u32.

u32, from into FooBar, field4, set_field4: 10, 0;

will generate the following setter:

fn set_field4(&mut self, value: FooBar) {
    use bitfield::BitRange;
    self.set_bit_range(10, 0, bitfield::Into::<u32>::into(value));
}

This allows making more uniform APIs to access fields.

[dzamlo]

Thanks a lot for your pull request!

Maybe we should make the setter generic and accept any T: From (or the type of the field), even if we don't specify a keyword. This way all setter will be more flexible. What do think? Do you see any drawbacks to that?

Also, I don't see any tests. I will have time on Monday to add them if you don't do that in the meantime.

[roblabla]

Maybe we should make the setter generic and accept any T: From (or the type of the field), even if we don't specify a keyword.

I don't think that's better. From a documentation perspective, I want the setter to take a specific type so the user can easily access that type and get more documentation about it. As a practical example, here I want to ensure the user will only ever handle instances of DeliveryMode. Its representation as an u32 should be an implementation detail.

And yeah, I didn't write any tests (apart from the doctest I guess). I'll make up some time tomorrow to write them :).

[dzamlo]

Released in 0.13.2

[dzamlo]

I thought of something else. It would be a breaking change, but wouldn't it make sense to set the setter type when there is just the into keyword? Making the from useless.

• no into: both the getter and setter get the normal type
• into: both the getter and setter get the into type
• if you want different type for the getter and setter, use two field, with _ as the setter for one and _ as the getter for the other.

The where you want into with a setter that use another seems pretty rare. And you can still achieve that with two field.

[roblabla]

Yeah, I didn't want to make a breaking change but having into alone affect the setter seems ideal. If this is going to be tackled, it'd be nice to fix #7 at the same time since it would also require a breaking change.