This is about the closest you can get currently without macros. The closest I would probably ever want that still explicitly involved a struct would be
With function defaults I would expect to be able to do this without ever defining an Options struct at all, and be able to write has_default_args(x = 56, ..default()) or even has_default_args(x=56). But these latter two forms have a whole lot of other implications.
Yeah, there's a few schools of thought for named arguments:
Use structs / builders, but make them easier to use. That's what _ was - it's a proposal to apply type inference to type names when constructing them. There are other proposals in this realm too, like the .. syntax proposal mentioned by CAD97.
Allow names to be given to parameters. There's a lot of options here about ordering, public vs private names, overloading, interactions with the type system, etc.
Adding anonymous structs. Basically we have structs with fields (named & labeled/fields) and tuple structs (named & ordered), and tuples (unnamed & ordered) right now. If we added a unnamed type with labeled values instead of ordered values, then we could use those in the type signatures of methods. This has it's own bag of worms too.
Almost all of these proposals have to deal type ascription on nightly, ha ha. And you could probably get several distinct proposals out of #2
One question: why? Except for being l'art pour l'art syntactic sugar, I don't see how this would accomplish anything that is not possible with today's Rust. And we definitely don't need more syntactic sugar that doesn't solve real problems. "It could work like this" is not a justification.
The reason is verbosity. But instead of taking an object as single parameter, we could apply the way 2) that @samsieber described, which instead allows to pass parameters by name... That could work well.
@Klaider The answer to this question is huge and complicated. Most of the context is summarized in this other thread, linked earlier. There is some agreement and some disagreement about which facets of this feature should ultimately be included, and there are a number of technical limitations that make it more than just picking some syntax. It's unfortunate, but I don't think you're going to get a satisfactory answer that isn't gigantic.