Rust 1.64.0(blog.rust-lang.org)
blog.rust-lang.org
Rust 1.64.0
https://blog.rust-lang.org/2022/09/22/Rust-1.64.0.html
33 comments
It’s sad that Rust has decided to settle with the builder pattern instead of implementing named arguments.
I'm pretty sure that there's no objection to including named arguments in Rust as of yet. It's just that no one has wanted it badly enough to write an RFC for, and implement, named arguments.
Can’t you pass “argument” structs as parameters to kinda emulate the feel of named arguments (along with using the Default trait)? I use this in C++ a lot, and it seems that some Rust devs are doing this too.
You can, but it is a mouthful. Especially if you want optional arguments.
foo::some_func(foo::SomeFuncArgs{
a: 8,
b: Some(false),
..Default::default()
})
foo::some_func(
a=8,
b=Some(false))By the way, C++20 designated initializers works like a charm for this.
foo::some_func({
.a = 8,
.b = false
});
I'm waiting to getting some spare time to propose (not quite but very close) that in an RFC. A lot of conversation about it from a while back is available at https://internals.rust-lang.org/t/pre-pre-rfc-syntactic-suga...
Indeed, it's basically the same as in JS/TS where you just pass an object of key/values rather than have named arguments.
Yes, but it is a lot cleaner there because you don't need to specify the name of the type and you don't need to do anything special for optional arguments.
I wouldn't mind if it worked this way "under the hood" but syntax sugar for passing that last argument as keyword arguments would be a fantastic quality of life improvement.
I wouldn't mind if it worked this way "under the hood" but syntax sugar for passing that last argument as keyword arguments would be a fantastic quality of life improvement.
Why? The builder pattern is great.
It gets awkward really fast when you may need to set a value.
let mut foo = build_foo()
.with_a(8);
if need_to_set_b {
foo = foo.with_b(false);
}
let foo = foo.build();Would look very similar with named arguments, no?
Not if you do what Dart did: https://medium.com/dartlang/making-dart-a-better-language-fo...
Maybe. It depends a bit on how they are implemented. If there is a good way to pass "default" then you can just have a condition for that one argument. But if there is no way to pass "default" then it can get hairy.
For sure. I would like to see that in Rust as well, that would be nice. I am willing to put up with the lack of variadic & named arguments for the goodness the borrow checker brings me, but I can see how that would improve the ergonomics substantially.
Having both approaches available would be better IMHO. Builder pattern is very nice but I frequently miss having named arguments too. Even if macros can partially fullfill that need, it's not the same and introduces more quirks and complexity...
Problem with named parameters is that they make renaming function params a breaking change.
Unless the IDE doesn’t support this refactoring? It’s ridiculously easy in C# and VS or VSC.
Fair enough.
Please note the programmer needs to implement "IntoFuture" and has full control on what and how it would be translated into a future. The example is implemented like this, but it does not have to be.
And yes, the example is not the best.
And yes, the example is not the best.
Aah, yeah that felt a bit off at the time of reading, nice note. I barely had time to keep up with this update and the changes... :p
I think the concept is that you are awaiting the "request type". And getting back a "response type". The example is somewhat confusing since set_debug() returns a StorageRequest.
With tooling this would make your resulting type be a StorageResponse. The whole point is that you can have that "request type" be awaitable.
With tooling this would make your resulting type be a StorageResponse. The whole point is that you can have that "request type" be awaitable.
Apparently, there's another meaning to word "simpler", of which I'm unaware :D
You may be thinking of "primitive", "simplistic" or "spartan". Things that are simple to use are not necessarily primitive.
It's simpler for library users, because they don't need to know which particular method finalizes a builder to obtain a future from it, and `.await` just works in more situations.
It's simpler for library users, because they don't need to know which particular method finalizes a builder to obtain a future from it, and `.await` just works in more situations.
That's not quite the best example as someone else noted, you could better of write an API where converting to Future can be a shore of in places where await may work in the Future.
Say, `for await x in connection.item {}` not real syntax but something similar might be in Rust's future.
Say, `for await x in connection.item {}` not real syntax but something similar might be in Rust's future.
Still no GAT
Next release, I believe, along with let-else.
What is that ?
My sibling has the super details, but at a high level:
Rust lets you have generic types on structs and functions:
Rust lets you have generic types on structs and functions:
// T is a generic type parameter, x has type T
fn foo<T>(x: T) -> {
trait MyIterator {
type Item;
fn next(&mut self) -> Option<Self::Item>;
}
struct Alternate {
state: i32,
}
impl MyIterator for Alternate {
// because we choose the Item type here...
type Item = i32;
// that determines the type that gets returned down here
fn next(&mut self) -> Option<Self::Item> {
// lifetimes are generics, so if you try this...
trait MyIterator {
type Item<'a>;
// you'll get this error message
error[E0658]: generic associated types are unstable
Generic Associated Types
https://rust-lang.github.io/generic-associated-types-initiat...
https://rust-lang.github.io/generic-associated-types-initiat...
I fail to see how hiding self.send() inside of IntoFuture makes anything simpler.
StorageRequest::new().set_debug(true).send().await?;
vs
StorageRequest::new().set_debug(true).await?;
Just reading the later variant makes me wonder "What are we (a)waiting for here? For set_debug to succeed?". I'd definitely stick to the former variant.
Perhaps, it's just not the best example and there are better usages than the one chosen to illustrate it.