5 ms·

Rust 1.64.0

71 points by 0xedb 4y ago

racketprogram 4y ago
curious145454 4y ago
> This takes a bit more code to implement, but provides a simpler API for users. 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.
- Jatidude 4y ago
  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.
  - curious145454 4y ago
    Apparently, there's another meaning to word "simpler", of which I'm unaware :D
    - pornel 4y ago
      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.
    - minraws 4y ago
      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.
- david2ndaccount 4y ago
  It’s sad that Rust has decided to settle with the builder pattern instead of implementing named arguments.
  - cyber_kinetist 4y ago
    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.
    - kevincox 4y ago
      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() }) Personally I would be really happy if `..` could default to `..Default::default()` which would make this a lot cleaner. But even then needing to name a type for the argument struct is noisy. Language-integrated keyword arguments would make this a lot cleaner: foo::some_func( a=8, b=Some(false))
      - cercatrova 4y ago
        Indeed, it's basically the same as in JS/TS where you just pass an object of key/values rather than have named arguments.
        kevincox 4y ago
        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.
      - cyber_kinetist 4y ago
        By the way, C++20 designated initializers works like a charm for this. foo::some_func({ .a = 8, .b = false }); (I view this and std::span as the only two usable features in C++20, and pretty much everything else can go to the dustbin or the drawing board.)
- ameixaseca 4y ago
  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.
  - minraws 4y ago
    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
hsfzxjy 4y ago
Still no GAT
- mbStavola 4y ago
  Next release, I believe, along with let-else.
- pjerem 4y ago
  What is that ?
  - noisem4ker 4y ago
    Generic Associated Types https://rust-lang.github.io/generic-associated-types-initiative/mvp.html https://rust-lang.github.io/generic-associated-types-initiat...
  - steveklabnik 4y ago
    My sibling has the super details, but at a high level: 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) -> { Rust also lets you have "associated types": 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> { In today's Rust, `type Item` cannot be a generic type: // 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 In the near future, combining these two features will be allowed.

71 points by 0xedb 4y ago

> This takes a bit more code to implement, but provides a simpler API for users. 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.

Jatidude 4y ago
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.
- curious145454 4y ago
  Apparently, there's another meaning to word "simpler", of which I'm unaware :D
  - pornel 4y ago
    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.
  - minraws 4y ago
    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.
david2ndaccount 4y ago
It’s sad that Rust has decided to settle with the builder pattern instead of implementing named arguments.
- cyber_kinetist 4y ago
  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.
  - kevincox 4y ago
    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() }) Personally I would be really happy if `..` could default to `..Default::default()` which would make this a lot cleaner. But even then needing to name a type for the argument struct is noisy. Language-integrated keyword arguments would make this a lot cleaner: foo::some_func( a=8, b=Some(false))
    - cercatrova 4y ago
      Indeed, it's basically the same as in JS/TS where you just pass an object of key/values rather than have named arguments.
      - kevincox 4y ago
        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.
    - cyber_kinetist 4y ago
      By the way, C++20 designated initializers works like a charm for this. foo::some_func({ .a = 8, .b = false }); (I view this and std::span as the only two usable features in C++20, and pretty much everything else can go to the dustbin or the drawing board.)
ameixaseca 4y ago
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.
- minraws 4y ago
  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

hsfzxjy 4y ago

Still no GAT

mbStavola 4y ago
Next release, I believe, along with let-else.
pjerem 4y ago
What is that ?
- noisem4ker 4y ago
  Generic Associated Types https://rust-lang.github.io/generic-associated-types-initiative/mvp.html https://rust-lang.github.io/generic-associated-types-initiat...
- steveklabnik 4y ago
  My sibling has the super details, but at a high level: 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) -> { Rust also lets you have "associated types": 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> { In today's Rust, `type Item` cannot be a generic type: // 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 In the near future, combining these two features will be allowed.