2 ms·

> and IMO Rust should never get them I guess whatever floats your boat. Personally, I enjoy not having to write functions like doStuff(true, true, true, false)

by yoz-y 6y ago

> and IMO Rust should never get them I guess whatever floats your boat. Personally, I enjoy not having to write functions like doStuff(true, true, true, false) or alternatively define types for every single boolean flag I want to have. Terseness is a non goal for Swift. > And on the first half of the file there are a bunch of POD struct definitions with a few init functions. I don't know how rust handles this but in swift, each POD struct has an implicit member wise constructor visible from the file it's defined. This is for encapsulation purposes, as its signature of course changes if you add fields to the struct.

est31 6y ago
> Personally, I enjoy not having to write functions like doStuff(true, true, true, false) Yeah that's not beautiful, but most of my code is rather doStuff(foo, bar, baz) where foo, bar and baz are descriptive variable names. I agree that it's hard to understand with literals, but in the rare cases you need such flags you can either have a config struct or use the builder pattern. Also, nowadays you can set up vscode to use the rust-analyzer LSP plugin, which shows you the types as well as the parameter names. But of course that doesn't work on Github and similar places. IDK in general, the people who want named arguments outnumber the people who don't want them, at least in threads about the question, which obviously preselects the people who want them. Maybe eventually Rust will get them, no idea. But IMO that code shows how named arguments can make code more noisy than before. > I don't know how rust handles this but in swift, each POD struct has an implicit member wise constructor visible from the file it's defined. This is for encapsulation purposes, as its signature of course changes if you add fields to the struct. In Rust, POD structs can be constructed iff all their members are visible through the publicity system to the code that tries to construct them. If it's in a different crate, it's also important whether there is a #[non_exhaustive] attribute on the struct declaration or not.
- user-the-name 6y ago
  > where foo, bar and baz are descriptive variable names But descriptive variable names should describe what those variables ARE, not how they are going to be passed to a function. So, does copy(tempFile, databaseFile) copy the temporary file over the database file, or vice versa?

by yoz-y 6y ago

est31 6y ago

> Personally, I enjoy not having to write functions like doStuff(true, true, true, false) Yeah that's not beautiful, but most of my code is rather doStuff(foo, bar, baz) where foo, bar and baz are descriptive variable names. I agree that it's hard to understand with literals, but in the rare cases you need such flags you can either have a config struct or use the builder pattern. Also, nowadays you can set up vscode to use the rust-analyzer LSP plugin, which shows you the types as well as the parameter names. But of course that doesn't work on Github and similar places. IDK in general, the people who want named arguments outnumber the people who don't want them, at least in threads about the question, which obviously preselects the people who want them. Maybe eventually Rust will get them, no idea. But IMO that code shows how named arguments can make code more noisy than before. > I don't know how rust handles this but in swift, each POD struct has an implicit member wise constructor visible from the file it's defined. This is for encapsulation purposes, as its signature of course changes if you add fields to the struct. In Rust, POD structs can be constructed iff all their members are visible through the publicity system to the code that tries to construct them. If it's in a different crate, it's also important whether there is a #[non_exhaustive] attribute on the struct declaration or not.

user-the-name 6y ago
> where foo, bar and baz are descriptive variable names But descriptive variable names should describe what those variables ARE, not how they are going to be passed to a function. So, does copy(tempFile, databaseFile) copy the temporary file over the database file, or vice versa?