Struct sugar

[bvssvni]

One can use overloading to get rid of the ‘…’ syntax for named arguments:

fn slice(&self, from: uint = 0, to: self.len()) { ... }
fn slice(&self, from: uint = 0) { self.slice(from, self.len()) }

foo.slice(from: 0, to: 10);
foo.slice(from: 0);

[bvssvni]

One alternative is to require named calling syntax on overloaded functions. This will force the programmer to refactor into structs instead of struct tuples.

[bvssvni]

It might be possible to allow overloading with a mixture of enum variants and function arguments. It works when enum variants have different type signatures and the signatures of normal functions are treated separately from the enums.

[bvssvni]

We can choose to go with:

• Only struct sugar, which will enable defaults
• Only enum sugar, which will enable overloading
• Both struct and enum sugar, which will enable both

In my opinion I think we should drop enum sugar because of the trait system. It makes it harder to look up in the documentation.

[bvssvni]

I think that overriding the tuple syntax might not be a bad idea after all. When having a vector of structs, it could be nice to write it like tuples:

// Struct sugar
let foo: Vec<Foo> = vec![
    { first_name: "John", last_name: "Red" },
    { first_name: "Donald", last_name: "Green" },
    { first_name: "Mike", last_name: "Orange" }
]

// Tuple sugar for structs
let foo: Vec<Foo> = vec![
    ("John", "Red"),
    ("Donald", "Green"),
    ("Mike", "Orange")
]

This also makes it possible to call a function that takes a struct as a normal function.

[bvssvni]

The tuple sugar can be an implicit cast into the struct, but only if all members of the struct are public. The same goes for implicit cast into the tuple struct.

Struct:

• x: val1, y: val2 =desugar> Foo { x: val1, y: val2 }
• { x: val1, y: val2 } =desugar> Foo { x: val1, y: val2 }
• (val1, val2) =implicit cast> Foo { x: val1, y: val2 }

When only brackets are specified, it counts as a block, so this does not actually count as desugar.

Struct tuple:

(val1, val2) =implicit cast> Foo(val1, val2)

[SiegeLord]

Using structs to fake keyword arguments is a giant hack (it requires unergonomic declaration and use of an argument struct). I’d rather keep using a macro for that use case even if this sugar was implemented.

[bvssvni]

Not necessarily, read rest of the comments.

[SiegeLord]

Not necessarily, read rest of the comments.

I don’t know what you’re referring to. The totality of your comments deal with the call site, while I am talking about using struct declaration and use. Any struct syntax sugar will require this preamble and usage:

struct FuncArgs {
    arg1: int = 1,
    arg2: int = 2,
    arg3: int = 3,
}

fn func(args: FuncArgs) -> int {
    args.arg1 + args.arg2 + args.arg3
}

vs

fn func(arg1: int = 1, arg2: int = 2, arg3: int = 3) -> int {
    arg1 + arg2 + arg3
}

One looks like a proper feature, and one looks like a hack.

[bvssvni]

The idea is to support both, allow refactoring into a struct when you need it. This is probably how I would write it:

fn func(FuncArgs { arg1, arg2, arg2 }) -> int {
    arg1 + arg2 + arg3
}

[krdln]

What I like in this proposal is that it’s not adding any features to Rust except of sugar (which you don’t have to use) that compiles to currently legal Rust code. It is kind of hack, butit’s not uncommon to pass a structure as an argument, when they are complicated enough. Another advantage of this approach (in comparison to keyword arguments as a language feature) is that it’s always simply a struct: it’s obvious when it’s evaluated and how it is passed to callee; and you enable caller to store that struct anywhere and pass it as a single value.

Unergonomic declaration isn’t that bad, because you delcare function only once, but it can be sugared too, or at least wrapped behind a simple macro too, so I don’t think is a problem.

One think I don’t agree with @bvssvni is making None special. While it may save few keystrokes, i think it adds really a lot complexity and it’s not obvious.

[krdln]

This also makes it possible to call a function that takes a struct as a normal function.

I guess that not really, you would either have to call foo((1,2)) or introduce ambiguity. Moreover, it would require introducing either implicit casts from tuples or fallback to tuples, for that to work:

let arg = (1,2); // treat it as truct literal here
foo(arg); // or implicitely cast here?

similarly as following would:

let arg = x: 1, y: 2; // obvious that it's a struct
foo(arg);

Anyway, I think one of the reasons why Rust currently requires field names in struct declaration is to make it obvious without consulting struct definition and being immune to reordering of fields. Let’s keep it that way and let tuples stay tuples.

[SiegeLord]

You can’t fix every ergonomic issue with a macro. For one, the documentation of the field names of this argument struct will be separate from the documentation function that takes those arguments. The languages that encourage passing structs when there are too many arguments are also languages without keyword arguments, so I reject that line of reasoning (at least, I can’t think of an API in Python that does this instead of using keyword arguments). I really don’t see what is gained by convoluting the otherwise interesting feature of default member values for something that it is very ill suited for. In particular, I still find that all of the proposed syntaxes are inferior to the procedural macro I made to solve this problem.

Additionaly, this duality is similar to struct variants and tuple variants with a struct value. I find them both useful at different times.

[bvssvni]

We should make struct sugar as good as possible before we decide whether to put it in Rust. I think the summary is based on results from the analysis, but there could be more analysis to improve it. What we want is as few rules as possible that cover all cases.

[bvssvni]

Instead of implicit casting from tuples, we can desugar

x, y

into

Foo { x: x, y: y }

This preserves ordering and requires the names to match. It will give errors when names do not match if the function takes a struct, but not for normal funtion arguments.

When refactoring, you always use a named struct, so we can drop struct tuples from the RFC.

[bvssvni]

I think we should drop default values for struct members, since they are confusing and less flexible than non-static expressions.

With struct sugar, it will take little effort to write a constructor with the default values per member.

[bvssvni]

An idea to improve refactoring is to use a colon after ‘pub’ to make all members public.

pub: struct Foo {
    bar: uint,
    baz: uint
}

[bvssvni]

We could match against argument name when one argument uses named syntax:

// These calls do the same
foo(x, y, z: 0);
foo(y, x, z: 0);
foo(z:0, y, x);

If a name does not match, there will be a compiler error.

[bvssvni]

One idea from discussion on reddit:

To avoid special casing on Option, we could have a rule that the first enum variant with no type signature is matched against. There must be 2 variants, one empty and one with a single type. The reason it can only be a single type is because it needs to be unwrappable and the internal type must be the unwrapped type.

For example:

pub enum MoviesLimit {
    AllMovies,
    Number(uint)
}

fn get_best_movies(&self, limit: MoviesLimit = self.len()) { ... }

This will require typing the full type.

fn foo(&self, limit: Option<uint> = 2);

[bvssvni]

One idea is to use the returned value of the Default trait to match against.