[flagged]
When used in code, it also results in many folding API branches such as Foo::new(port=8088, host="localhost") or Foo::new(pipe="./myfile") – Rust preferred idiom here would be Foo::new_listen("localhost", "8088) or Foo::new_pipe("./pipefile"). So at this point idiomatic Rust is preferred.
Also named parameters amplify your API naming fail surface (think misspellings!) beyond structs and impl functions... Like in "max_connexions" (sic), which is actually an unintended typo in one of the RFC proposals for naming parameters in Rust! It's hilarious.
Default parameters: my_port.unwrap_or(8080)
Variadics: useful, but needs to be carefully considered. There are workarounds now in nightly for C compatibility. There also concerns about how "..." and ".." syntax play out and incompatibilities on different implementation targets. And, yes, safety issues.
It's not that Rust people will mumble about safety. It's that it would be stupid to design a language all around safety and then implement every cool language feature in the world today without scrutinizing them for safety issues.
2. Every other modern language makes this work, only rust makes excuses.
3. Rust already has default generic type arguments and “named parameters” for struct constructors (which in fact are mandatory), for which the same criticisms also apply to.
Rust is already tedious enough to work with as is, and the last thing it needs is more builder pattern or manual name mangling. You already need mut/non mut for getters, sync/async, etc. just look at [serde](https://docs.rs/serde/latest/serde/trait.Deserializer.html) or polars or ndarray. Ugliest language ever.
Like I said, if the feature is not compatible with the core principles of the language maybe they shouldn't be in it. Look for the issues in Github you'll see how and why the feature is not in the language. No excuses. All debatable, but arguments do make sense. And go make your case there!
You absolutely don't need to do manual name mangling. It sure does have things in common with how struct literals work, and in fact you can use them right now with some of the common patterns for named parameters in Rust:
foo( FooConfig::new().host("localhost").port(8080) );
enum Param {
Listen { host: String, port: u16 },
Pipe { file: String },
};
foo( Param::Listen { host: "locahost", port: 8080 } );
foo( Param::Pipe { file: "./pipe".to_string() } );
plot( y=100, z=300, x=200 ); --> the order of x,y,z makes it hard to read!
plot( 200, 100, 300); --> much better!
Yeah, then we can have Rust bloated like C++, a untractable codebase and many ways to do it.
So hard that Ada, Swift, C#, OCaml, Modula-3 have them.
Swift coincidentally has a slow compilation time thread today on HN's front page.
Ada, OCaml, Modula-3... come on, we're talking about a combined 100+ years development time. That's plenty of time to ship pink-laced kittens bolted into the syntax.
C# has dynamic typing and a lot of dynamic features are done by the ASP.NET runtime. Not comparable.
C# named arguments don't have anything to do with COM dynamic support, learn about what you are actually talking about.
Swift slow compilation time doesn't have anything to do with named arguments, on top of that, contrary to Rust, has a stable ABI and support for native libraries, no need to compile the world from scratch as it happens with Rust. Again nothing to do with named arguments.
They would accept new proposals for these if you want to contribute, or just continue complaining.