Named & Default Arguments - A Review, Proposal and Macro Implementation

[scottmcm]

@samsieber

Regarding the quoted code - that’s valid syntax, but it would fail to compile because the types don’t match. Part of my proposal is that we type check blocks like {answer} to see if it should be treated as a one-field struct or as a block returning the value of answer . Granted, there are cases where this could be a breaking change - consider the situation where the return type is an impl trait, and both the struct and the single field inside it both implement the trait.

This kind of fallback tends to be particularly troublesome once the situations get more complex. Like does {{a}} mean S{a:{a}} or {S{a}}? The parser would have to generate some sort of "I'm not sure" AST that would get changed into the actual expressions after type checking, or something? It's pretty awkward.

Also, I think the parser would rather not need to use lookahead to decide what to do on seeing a {. (Though I wish bare braces would just work...)

@samsieber

What I love about the struct sugar approach is that we don’t even need to consider that question - we already have structs to encode name: value pairs in the type system. And with struct sugar any improvements to structs are trivially carried over to named & default arguments for functions. We get to use structs instead of modifying the type system.