Должен ли я вернуться ждать в Русте?

Question

В JavaScript асин * c код написан с обещаниями и синтаксисом async / await, аналогичным Rust. Обычно считается избыточным (и поэтому не рекомендуется) возвращать и в ожидании Promise, когда его можно просто вернуть (т. Е. Когда асинхронная функция c выполняется как последняя вещь в другой функции):

async function myFn() { /* ... */ }

async function myFn2() {
  // do setup work

  return await myFn()
  // ^ this is not necessary when we can just return the Promise
}

Мне интересно, применяется ли подобный шаблон в Rust. Должен ли я предпочесть это:

pub async fn my_function(
    &mut self,
) -> Result<()> {
    // do synchronous setup work

    self.exec_command(
        /* ... */
    )
    .await
}

Или это:

pub fn my_function(
    &mut self,
) -> impl Future<Output = Result<()>> {
    // do synchronous setup work

    self.exec_command(
        /* ... */
    )
}

Первый мне кажется более эргономичным c, но я подозреваю, что последний может быть более производительным. Это тот случай?

Answer 1

Одно семантичное c различие между этими двумя вариантами состоит в том, что в первом варианте код синхронной установки будет выполняться только тогда, когда ожидается возвращенное будущее, а во втором варианте он будет работать, как только будет вызвана функция:

let fut = x.my_function();
// in the second variant, the synchronous setup has finished by now
...
let val = fut.await;  // in the first variant, it runs here

Чтобы разница была заметной, код синхронной установки должен иметь побочные эффекты, и должна быть задержка между вызовом функции asyn c и ожиданием будущего ее возврата.

Если у вас нет конкретной c причины для немедленного выполнения преамбулы, go с помощью функции asyn c, т.е. первого варианта. Это делает функцию немного более предсказуемой и облегчает добавление большего количества ожидающих позже при рефакторинге функции.

Answer 2

Нет реальной разницы между ними, поскольку asyn c просто разрешается до impl Future<Output=Result<T, E>>. Я не верю, что между ними есть какая-либо значимая разница в производительности, по крайней мере, в моем эмпирическом использовании обоих.

Если вы просите о предпочтении стиля, то, по моему мнению, первое предпочтительнее в качестве типов мне понятнее, и я согласен, что это более эргономично c.