Go back to Args?

[bvssvni]

I read in the minute logs that struct variants will possibly be removed. https://github.com/rust-lang/meeting-minutes/blob/master/workweek-2014-08-18/versioning.md

pcwalton: Struct variants? nmatsakis: I'd like to drop those

Should we go back to Args?

Should we try arguing for keeping struct variants in the language?

[bvssvni]

Struct variants has the benefit of:

• Increased safety by matching members on the name
• Making match arms shorter: Input(input::MouseMove { draw_x, draw_y, .. }) => instead of Input(input::MouseMove(input::MouseMoveArgs { draw_x, draw_y, .. })) =>
• Reduces amount of code
• Encourages event threading and application focused refactoring. User input is handled through one method, while other methods don't depend on the input API. This leads to easier maintenance and less problems with nested widget hierarchies.

[bvssvni]

That said, it isn't bad to have Input(input::MouseMove(args)) =>. For the pattern we need, this actually makes the code look a bit nicer when you are mapping directly to an application specific method. However, this is a pattern that might have drawbacks. Other methods should use function arguments so you can use them easily through other means.

[bvssvni]

Here is an example with tuple variants:

https://github.com/PistonDevelopers/piston-examples/blob/2df5a8c124cf1d6e0df8ec4cfa6e89056fda82e0/user_input/src/main.rs#L106

Here is the same example with struct variants: https://github.com/PistonDevelopers/piston-examples/blob/15c8a4f91724d312521b39fa81713b8f90706fbe/user_input/src/main.rs#L89

Notice that it looks nicer with tuple variants, but in a real world example you often want to map the whole InputEvent directly Input(e) => controller.event(&e). In such cases it won't make a difference.