Rust 1.64.0

https://blog.rust-lang.org/2022/09/22/Rust-1.64.0.html

by 0xedb • 4 years ago

71 32 4 years ago

blog.rust-lang.org

curious1454542• 4 years 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?;

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• 4 years 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.

curious1454542• 4 years ago

Apparently, there's another meaning to word "simpler", of which I'm unaware :D

david2ndaccount• 4 years ago

It’s sad that Rust has decided to settle with the builder pattern instead of implementing named arguments.

cyber_kinetist2• 4 years 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.

maxbond4• 4 years ago

Why? The builder pattern is great.

davidatbu• 4 years ago

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.

ameixaseca• 4 years 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.

minraws2• 4 years 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• 4 years ago

Still no GAT

mbStavola• 4 years ago

Next release, I believe, along with let-else.

pjerem• 4 years ago

What is that ?

noisem4ker• 4 years ago

Generic Associated Types

https://rust-lang.github.io/generic-associated-types-initiat...

steveklabnik• 4 years 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.

Rust 1.64.0

Related Stories