Announcing Rust 1.19

Re:Announcing Rust 1.19 by piaste on Friday July 21, 2017 @05:11AM (#14819089)

I agree about default values, but named parameters have other benefits beyond acting as makeshift configuration options.

1) More readable code. The classic is foo.Bar(true). It breaks the flow of reading to have to hover and see what that 'true' means. Much nicer to see foo.bar(launchMissiles: true).

2) Protects from a particular class of dumb mistakes. You have a function foo(x, y) where x and y have the same type. You refactor it so that one of the parameters isn't needed anymore. It's surprisingly easy (read: I've seen it, and I've done it), when you clean up the function calls, to accidentally delete x instead of y or vice-versa. Named parameters prevent that.

[ Parent | on HN ]

Re:Announcing Rust 1.19 by wtetzner on Friday July 21, 2017 @09:36AM (#14820387)

> 1) More readable code. The classic is foo.Bar(true). It breaks the flow of reading to have to hover and see what that 'true' means. Much nicer to see foo.bar(launchMissiles: true).

This is a case where I've started using Enums in Java. For example:

    foo.bar(LaunchMissiles.YES);

In Rust, you could have a macro to make defining these types easier (and have it automatically generate to_bool and from_bool methods):

    named_bool!(LaunchMissiles);
    foo.bar(LaunchMissiles::Yes);

[ Parent | on HN ]