Achei que poderia ser útil escrever como outras linguagens lidam com uma construção de await.

Kotlin

val result = task.await()

C

var result = await task;

F

let! result = task()

Scala

val result = Await.result(task, timeout)

Pitão

result = await task

JavaScript

let result = await task;

C ++ (corrotinas TR)

auto result = co_await task;

Hackear

$result = await task;

Dardo

var result = await task;

Com tudo isso, vamos lembrar que expressões Rust podem resultar em vários métodos encadeados. A maioria das línguas tende a não fazer isso.

Com tudo isso, vamos lembrar que expressões Rust podem resultar em vários métodos encadeados. A maioria das línguas tende a não fazer isso.

Eu diria que as linguagens que suportam métodos de extensão tendem a tê-los. Isso incluiria Rust, Kotlin, C # (por exemplo, sintaxe de método LINQ e vários construtores) e F #, embora o último use intensamente o operador de pipe para o mesmo efeito.

Puramente anedótico da minha parte, mas eu regularmente executo uma dúzia de expressões encadeadas de método no código Rust em estado selvagem e ele é lido e executado bem. Eu não experimentei isso em outro lugar.

Gostaria de ver que esse problema foi referido na postagem superior de # 50547 (ao lado da caixa de seleção "Sintaxe final para espera.").

Kotlin

val result = task.await()

A sintaxe de Kotlin é:

val result = doTask()

O await é apenas suspendable function , não uma coisa de primeira classe.

Obrigado por mencionar isso. Kotlin parece mais implícito porque os futuros são ansiosos por padrão. No entanto, ainda é um padrão comum em um bloco adiado usar esse método para esperar por outros blocos adiados. Certamente já fiz isso várias vezes.

@cramertj Visto que há 276 comentários em https://github.com/rust-lang/rust/issues/50547 , você poderia resumir os argumentos apresentados ali para tornar mais fácil não repeti-los aqui? (Talvez adicioná-los ao OP aqui?)

Kotlin parece mais implícito porque os futuros são ansiosos por padrão. No entanto, ainda é um padrão comum em um bloco adiado usar esse método para esperar por outros blocos adiados. Certamente já fiz isso várias vezes.

talvez você deva adicionar ambos os casos de uso com um pouco de contexto / descrição.

Além disso, o que há com outros langs usando espera implícita, como go-lang?

Uma razão para ser a favor de uma sintaxe pós-correção é que, da perspectiva dos chamadores, um await se comporta muito como uma chamada de função: você abre mão do controle de fluxo e, quando o recebe de volta, um resultado está esperando em sua pilha. Em qualquer caso, eu preferiria uma sintaxe que abrace o comportamento semelhante a uma função, contendo parênteses de função. E há boas razões para querer dividir a construção de co-rotinas de sua primeira execução para que esse comportamento seja consistente entre blocos de sincronização e assíncronos.

Mas, embora o estilo de co-rotina implícito tenha sido debatido e eu esteja do lado da explicitação, chamar uma co-rotina não seria suficientemente explícito? Provavelmente, isso funciona melhor quando a co-rotina não é usada diretamente onde foi construída (ou pode funcionar com fluxos). Em essência, em contraste com uma chamada normal, esperamos que uma co-rotina demore mais do que o necessário em uma ordem de avaliação mais relaxada. E .await!() é mais ou menos uma tentativa de diferenciar entre chamadas normais e chamadas de co-rotina.

Então, depois de ter fornecido uma abordagem um tanto nova sobre por que a pós-correção poderia ser preferida, uma humilde proposta de sintaxe:

• future(?)
• ou future(await) que vem com suas próprias compensações, é claro, mas parece ser aceito como menos confuso, consulte o final da postagem.

Adaptando um exemplo bastante popular de outro thread (assumindo que logger.log também seja uma co-rotina, para mostrar o que a chamada imediata parece):

async fn log_service(&self) -> T {
   let service = self.myService.foo(); // Only construction
   self.logger.log("beginning service call")(?);
   let output = service(?); // Actually wait for its result
   self.logger.log("foo executed with result {}.", output)(?);
   output
}

E com a alternativa:

async fn log_service(&self) -> T {
   let service = self.myService.foo(); // Only construction
   self.logger.log("beginning service call")(await);
   let output = service(await);
   self.logger.log("foo executed with result {}.", output)(await);
   output
}

Para evitar código ilegível e ajudar na análise, só permita espaços após o ponto de interrogação, não entre ele e o paranormal aberto. Portanto, future(? ) é bom, enquanto future( ?) não seria. Este problema não surge no caso de future(await) onde todos os tokens atuais podem ser usados ​​como anteriormente.

A interação com outros operadores pós-correção (como o atual ? -try) também é semelhante às chamadas de função:

async fn try_log(message: String) -> Result<usize, Error> {
    let logger = acquire_lock()(?);
    // Very terse, construct the future, wait on it, branch on its result.
    let length = logger.log_into(message)(?)?;
    logger.timestamp()(?);
    Ok(length)
}

Ou

async fn try_log(message: String) -> Result<usize, Error> {
    let logger = acquire_lock()(await);
    // Very terse, construct the future, wait on it, branch on its result.
    let length = logger.log_into(message)(await)?;
    logger.timestamp()(await);
    Ok(length)
}

Alguns motivos para gostar disso:

• Comparado a .await!() , não faz alusão a um membro que poderia ter outros usos.
• Ele segue a precedência natural de chamadas, como encadeamento e uso de ? . Isso mantém o número de classes anteriores mais baixo e ajuda no aprendizado. E as chamadas de função sempre foram um tanto especiais na linguagem (embora tenham uma característica), de modo que não há expectativa de que o código do usuário seja capaz de definir seu próprio my_await!() que tem sintaxe e efeitos muito semelhantes.
• Isso poderia generalizar para geradores e fluxos, bem como geradores que esperam que mais argumentos sejam fornecidos na retomada. Em essência, isso se comporta como FnOnce enquanto Streams se comporta como FnMut . Argumentos adicionais também podem ser acomodados facilmente.
• Para aqueles que usaram os Futures atuais antes, isso mostra como ? com Poll deveria ter funcionado o tempo todo (infeliz sequência de estabilização aqui). Como uma etapa de aprendizado, também é consistente com a expectativa de que um operador baseado em ? desvie o fluxo de controle. (await) por outro lado não satisfaria isso, mas afinal a função sempre esperará retomar no ponto divergente.
• Ele usa uma sintaxe semelhante a uma função, embora este argumento só seja bom se você concordar comigo: smile:

E razões para não gostar disso:

• ? parece ser um argumento, mas nem mesmo se aplica a uma expressão. Eu acredito que isso poderia ser resolvido através do ensino, já que o símbolo ao qual parece ser aplicado é a própria chamada de função, que é a noção um tanto correta. Isso também significa positivamente que a sintaxe não é ambígua, espero.
• Uma mistura maior (e diferente) de parênteses e ? pode ser difícil de analisar. Especialmente quando você tem um futuro retornando o resultado de outro futuro: construct_future()(?)?(?)? . Mas você poderia usar o mesmo argumento para ser capaz de resultar em um objeto fn , levando a uma expressão como esta sendo permitida: foobar()?()?()? . Uma vez que, no entanto, nunca vi isso nem reclamar, a divisão em declarações separadas em tais casos parece raramente ser necessária. Este problema também não existe para construct_future()(await)?(await)? -
• future(?) é minha melhor chance de uma sintaxe concisa e ainda um tanto concisa. Ainda assim, seu raciocínio é baseado em detalhes de implementação em corrotinas (retornando temporariamente e despachando na retomada), o que pode torná-lo inadequado para uma abstração. future(await) seria uma alternativa que ainda poderia ser explicada após await ter sido internalizado como uma palavra-chave, mas a posição do argumento é um pouco difícil de engolir para mim. Pode funcionar e certamente é mais legível quando a co-rotina retorna um resultado.
• Interferência com outras propostas de chamadas de funções?
• Seu próprio? Você não precisa gostar disso, apenas pareceu um desperdício não pelo menos propor essa sintaxe pós-correção concisa.

future(?)

Não há nada de especial em Result : Futures podem retornar qualquer tipo de Rust. Acontece que alguns futuros retornam Result

Então, como isso funcionaria para Futuros que não retornam Result ?

Parece que não ficou claro o que eu quis dizer. future(?) é o que foi discutido anteriormente como future.await!() ou similar. Ramificar em um futuro que também retorna um resultado seria future(?)? (duas maneiras diferentes de como podemos abrir mão do fluxo de controle mais cedo). Isso torna a pesquisa futura (?) e o teste de resultados ? ortogonais. Editar: adicionado um exemplo extra para isso.

Ramificar em um futuro que retornasse um resultado também seria future(?)?

Obrigado por esclarecer. Nesse caso, definitivamente não sou fã disso.

Isso significa que chamar uma função que retorna Future<Output = Result<_, _>> seria escrita como foo()(?)?

Tem uma sintaxe ? para duas finalidades completamente diferentes.

Se for especificamente a dica para o operador ? que é pesado, é possível substituí-la pela palavra-chave recém-reservada. Eu tinha apenas inicialmente considerado que isso parecia muito com um argumento real do tipo intrigante, mas a compensação poderia funcionar em termos de ajudar a analisar mentalmente a declaração. Portanto, a mesma declaração para impl Future<Output = Result<_,_>> seria:

• foo()(await)?

O melhor argumento para que ? seja apropriado é que o mecanismo interno usado é um tanto semelhante (caso contrário, não poderíamos usar Poll nas bibliotecas atuais), mas isso pode perder o ponto de ser uma boa abstração.

É uma sintaxe muito pesada

Eu pensei que esse é todo o ponto de espera explícita?

ele usa? para dois propósitos completamente diferentes.

sim, então a sintaxe de foo()(await) seria muito melhor.

essa sintaxe é como chamar uma função que retorna um encerramento e, em seguida, chamar esse encerramento em JS.

Minha leitura de "sintaxe pesada" foi mais próxima de "sigilo pesado", ver uma sequência de ()(?)? é bastante chocante. Isso foi trazido na postagem original:

Uma mistura maior (e diferente) de parênteses e ? pode ser difícil de analisar. Especialmente quando você tem um futuro retornando o resultado de outro futuro: construct_future()(?)?(?)?

Mas você poderia usar o mesmo argumento para ser capaz de resultar em um objeto fn , levando a uma expressão como esta sendo permitida: foobar()?()?()? . Uma vez que, no entanto, nunca vi isso nem reclamar, a divisão em declarações separadas em tais casos parece raramente ser necessária.

Acho que a refutação aqui é: quantas vezes você viu -> impl Fn na natureza (quanto mais -> Result<impl Fn() -> Result<impl Fn() -> Result<_, _>, _>, _> )? Quantas vezes você espera ver -> impl Future<Output = Result<_, _>> em uma base de código assíncrona? Ter que nomear um valor de retorno impl Fn raro para tornar o código mais fácil de ler é muito diferente de ter que nomear uma fração significativa de valores de retorno impl Future temporários.

Ter que nomear um valor de retorno Fn impl raro para tornar o código mais fácil de ler é muito diferente de ter que nomear uma fração significativa de valores de retorno Futuro impl temporário.

Não vejo como essa escolha de sintaxe influencia o número de vezes que você precisa nomear explicitamente o tipo de resultado. Não acho que isso não influencie a inferência de tipo diferente de await? future .

No entanto, todos vocês fizeram observações muito boas aqui e quanto mais exemplos eu inventar com isso (editei o post original para sempre conter as duas versões de sintaxe), mais me inclino para future(await) . Não é irracional digitar e ainda retém toda a clareza da sintaxe de chamada de função que isso pretendia evocar.

Quantas vezes você espera ver -> impl Futuro

> em uma base de código assíncrona?

Espero ver o tipo equivalente a este (um fn assíncrono que retorna um Resultado) o tempo todo , provavelmente até mesmo a maioria de todos os fns assíncronos, pois se o que você está esperando é um IO par, você quase certamente lançará Erros de IO para cima.

Ligando para meu post anterior sobre o problema de rastreamento e adicionando mais algumas idéias.

Acho que há muito pouca chance de uma sintaxe que não inclua a cadeia de caracteres await ser aceita para esta sintaxe. Acho que neste ponto, após um ano de trabalho neste recurso, seria mais produtivo tentar pesar os prós e os contras das alternativas viáveis ​​conhecidas para tentar encontrar qual é melhor do que propor novas sintaxes. As sintaxes que considero viáveis, dadas minhas postagens anteriores:

• O prefixo aguarda com delimitadores obrigatórios. Aqui, também é uma decisão de quais delimitadores (colchetes ou parênteses ou aceitar ambos; todos esses têm seus próprios prós e contras). Ou seja, await(future) ou await { future } . Isso resolve completamente os problemas de precedência, mas é sintaticamente ruidoso e ambas as opções de delimitador apresentam possíveis fontes de confusão.
• O prefixo aguarda com a precedência "útil" em relação a ? . (Ou seja, que espera liga mais forte do que?). Isso pode surpreender alguns usuários que leem código, mas acredito que funções que retornam resultados futuros de resultados serão muito mais comuns do que funções que retornam resultados futuros.
• O prefixo aguarda com a precedência "óbvia" em relação a ? . (Ou seja, isso? Liga mais forte do que esperar). Sintaxe adicional sugar await? para uma combinação de await e? operador. Acho que esse açúcar de sintaxe é necessário para tornar essa ordem de precedência viável, caso contrário, todos estarão escrevendo (await future)? o tempo todo, que é uma variante pior da primeira opção que enumerei.
• Postfix await com o espaço de sintaxe await. Isso resolve o problema de precedência por ter uma ordem visual clara entre os dois operadores. Eu me sinto desconfortável com essa solução em muitos aspectos.

Minha própria classificação entre essas escolhas muda toda vez que examino a questão. A partir deste momento, acho que usar a precedência óbvia com o açúcar parece o melhor equilíbrio entre ergonomia, familiaridade e compreensão. Mas no passado eu favoreci qualquer uma das outras duas sintaxes de prefixo.

Para fins de discussão, darei a essas quatro opções esses nomes:

Nome Futuro | Futuro do Resultado | Resultado do Futuro
--- | --- | --- | ---
Delimitadores obrigatórios | await(future) ou await { future } | await(future)? ou await { future }? | await(future?) ou await { future? }
Precedência útil | await future | await future? | await (future?)
Precedência óbvia com açúcar | await future | await? future ou (await future)? | await future?
Palavra-chave Postfix | future await | future await? | future? await

(Eu usei especificamente "palavra-chave postfix" para distinguir esta opção de outras sintaxes postfix como "macro postfix".)

Uma das deficiências de 'abençoar' await future? em precedência útil, mas também outras que não funcionam como pós-correção, seria que os padrões usuais de conversão manual de expressões com ? podem não se aplicar mais, ou exigir que Future replique explicitamente os Result -métodos de uma forma compatível. Acho isso surpreendente. Se eles forem replicados, de repente se torna tão confuso quais dos combinadores funcionam em um futuro retornado e quais estão ansiosos. Em outras palavras, seria tão difícil decidir o que um combinador realmente faz quanto no caso de espera implícita. (Editar: na verdade, veja dois comentários abaixo, onde tenho uma perspectiva mais técnica do que quero dizer com substituição surpreendente de ? )

Um exemplo onde podemos nos recuperar de um caso de erro:

async fn previously() -> Result<_, lib::Error> {
    let _ = await get_result()?;
}

async fn with_recovery() -> Result<_, lib::Error> {
    // Does `or_recover` return a future or not? Suddenly very important but not visible.
    let _ = await get_result().unwrap_or_else(or_recover);
    // If `or_recover` is sync, this should still work as a pattern of replacing `?` imho.
    // But we also want `or_recover` returning a future to work, as a combinator for futures?

    // Resolving sync like this just feel like wrong precedence in a number of ways
    // Also, conflicts with `Result of future` depending on choice.
    let _ = await get_result()?.unwrap_or_else(or_recover);
}

Esse problema não ocorre para operadores reais de pós-correção:

async fn with_recovery() -> Result<_, lib::Error> {
    // Also possible in 'space' delimited post-fix await route, but slightly less clear
    let _ = get_result()(await)
        // Ah, this is sync
        .unwrap_or_else(or_recover);
    // This would be future combinator.
    // let _ = get_result().unwrap_or_else(or_recover)(await);
}

// Obvious precedence syntax
let _ = await get_result().unwrap_or_else(or_recover);

// Post-fix function argument-like syntax
let _ = get_result()(await).unwrap_or_else(or_recover);

Estas são expressões diferentes, o operador ponto tem uma precedência mais alta do que o operador de "precedência óbvia" await , então o equivalente é:

let _ = get_result().unwrap_or_else(or_recover)(await);

Isso tem exatamente a mesma ambiguidade de or_recover ser assíncrono ou não. (O que eu afirmo que não importa, você sabe que a expressão como um todo é assíncrona e pode examinar a definição de or_recover se, por algum motivo, precisar saber se essa parte específica é assíncrona).

Isso tem exatamente a mesma ambiguidade de or_recover ser assíncrono ou não.

Não exatamente igual. unwrap_or_else deve produzir uma co-rotina porque é esperada, então a ambigüidade é se get_result é uma co-rotina (então um combinador é construído) ou um Result<impl Future, _> (e Ok já contém uma co-rotina e Err cria uma). Ambos não têm as mesmas preocupações de ser capaz de identificar rapidamente o ganho de eficiência movendo um ponto de sequência await para um join , que é uma das principais preocupações de implícito espera. A razão é que, em qualquer caso, esse cálculo intermediário deve ser sincronizado e deve ter sido aplicado ao tipo antes de esperar e deve ter resultado na co-rotina esperada. Há uma outra preocupação maior aqui:

Estas são expressões diferentes, o operador ponto tem uma precedência mais alta do que o operador de espera de "precedência óbvia", então o equivalente é

Isso é parte da confusão, substituir ? por uma operação de recuperação mudou a posição de await fundamentalmente. No contexto da sintaxe ? , dada uma expressão parcial expr do tipo T , espero a seguinte semântica de uma transformação (presumindo que T::unwrap_or_else exista) :

• expr? -> expr.unwrap_or_else(or_recover)
• <T as Try>::into_result(expr)? -> T::unwrap_or_else(expr, or_recover)

No entanto, em 'Precedência útil' e await expr? ( await expr produz T ), em vez disso obtemos

• await expr? -> await expr.unwrap_or_else(or_recover)
• <T as Try>::into-result(await expr) -> await Future::unwrap_or_else(expr, or_recover)

ao passo que na precedência óbvia essa transformação não se aplica mais sem parênteses extras, mas pelo menos a intuição ainda funciona para 'Resultado do Futuro'.

E o caso ainda mais interessante em que você espera em dois pontos diferentes em uma seqüência combinadora? Com qualquer sintaxe de prefixo isso, eu acho, requer parênteses. O resto da linguagem Rust tenta evitar isso ao máximo para fazer 'expressões avaliadas da esquerda para a direita' funcionarem, um exemplo disso é a mágica auto-ref.

Exemplo para mostrar que isso fica pior para cadeias mais longas com vários pontos de espera / tentativa / combinação.

// Chain such that we
// 1. Create a future computing some partial result
// 2. wait for a result 
// 3. then recover to a new future in case of error, 
// 4. then try its awaited result. 
async fn await_chain() -> Result<usize, Error> {
    // Mandatory delimiters
    let _ = await(await(partial_computation()).unwrap_or_else(or_recover))?
    // Useful precedence requires paranthesis nesting afterall
    let _ = await { await partial_computation() }.unwrap_or_else(or_recover)?;
    // Obivious precendence may do slightly better, but I think confusing left-right-jumps after all.
    let _ = await? (await partial_computation()).unwrap_or_else(or_recover);
    // Post-fix
    let _ = partial_computation()(await).unwrap_or_else(or_recover)(await)?;
}

O que eu gostaria de ver evitado, é a criação do análogo Rust da análise de tipo C onde você pula entre
lado esquerdo e direito da expressão para combinadores de 'ponteiro' e 'matriz'.

Tabela de entrada no estilo @withoutboats :

| Nome Futuro | Futuro do Resultado | Resultado do Futuro |
| - | - | - | - |
| Delimitadores obrigatórios | await(future) | await(future)? | await(future?) |
| Precedência útil | await future | await future? | await (future?) |
| Precedência óbvia | await future | await? future | await future? |
| Chamada Postfix | future(await) | future(await)? | future?(await) |

| Nome Acorrentado |
| - | - |
| Delimitadores obrigatórios | await(await(foo())?.bar())? |
| Precedência útil | await(await foo()?).bar()? |
| Precedência óbvia | await? (await? foo()).bar() |
| Chamada Postfix | foo()(await)?.bar()(await) |

Eu sou fortemente a favor de um Postfix Aguardar por vários motivos, mas eu não gosto da variante mostrada por @withoutboats , principalmente parece pelos mesmos motivos. Por exemplo. foo await.method() é confuso.

Primeiro, vamos olhar para uma tabela semelhante, mas adicionando mais algumas variantes Postfix:

| Nome Futuro | Futuro do Resultado | Resultado do Futuro |
| ---------------------- | -------------------- | ----- ---------------- | --------------------- |
| Delimitadores obrigatórios | await { future } | await { future }? | await { future? } |
| Precedência útil | await future | await future? | await (future?) |
| Precedência óbvia | await future | await? future | await future? |
| Palavra-chave Postfix | future await | future await? | future? await |
| Campo Postfix | future.await | future.await? | future?.await |
| Método Postfix | future.await() | future.await()? | future?.await() |

Agora vamos olhar para uma expressão futura encadeada:

| Nome Futuros de resultados em cadeia |
| ---------------------- | -------------------------- ----------- |
| Delimitadores obrigatórios | await { await { foo() }?.bar() }? |
| Precedência útil | await (await foo()?).bar()? |
| Precedência óbvia | await? (await? foo()).bar() |
| Palavra-chave Postfix | foo() await?.bar() await? |
| Campo Postfix | foo().await?.bar().await? |
| Método Postfix | foo().await()?.bar().await()? |

E agora, para um exemplo do mundo real, de reqwests , de onde você pode querer esperar um futuro encadeado de resultados (usando meu formulário de espera preferido).

let res: MyResponse = client.get("https://my_api").send().await?.json().await?;

Na verdade, acho que todos os separadores parecem bons para sintaxe postfix, por exemplo:
let res: MyResponse = client.get("https://my_api").send()/await?.json()/await?;
Mas não tenho uma opinião forte sobre qual usar.

A macro Postfix (por exemplo, future.await!() ) ainda pode ser uma opção? É claro, conciso e inequívoco:

| Futuro | Futuro do Resultado | Resultado do Futuro |
| --- | --- | --- |
| futuro.esperado! () | futuro.autorizar! ()? | futuro? .await! () |

Além disso, a macro postfix requer menos esforço para ser implementada e é fácil de entender e usar.

Além disso, a macro postfix requer menos esforço para ser implementada e é fácil de entender e usar.

Além disso, está apenas usando um recurso de linguagem comum (ou pelo menos se pareceria com uma macro postfix normal).

Uma macro postfix seria legal, pois combina a sucinta e encadeada do postfix com as propriedades não mágicas e a presença óbvia de macros, e se encaixaria bem com macros de usuários de terceiros, como .await_debug!() , .await_log!(WARN) ou .await_trace!()

Uma macro pós-fixada seria boa, pois combina as [...] propriedades não mágicas das macros

@novacrazy, o problema com este argumento é que qualquer macro await! _seria_ mágica, está executando uma operação que não é possível no código escrito pelo usuário (atualmente a implementação baseada no gerador subjacente está um pouco exposta, mas meu entendimento é que antes da estabilização, ele ficará completamente oculto (e interagir com ele no momento requer o uso de alguns rustc -recursos noturnos internos)).

@ Nemo157 Hmm. Eu não sabia que era para ser tão opaco.

É tarde demais para reconsiderar o uso de uma macro procedural como #[async] para fazer a transformação da função "assíncrona" para a função do gerador, em vez de uma palavra-chave mágica? São três caracteres extras para digitar e podem ser marcados nos documentos da mesma forma que #[must_use] ou #[repr(C)] .

Não estou gostando da ideia de esconder tantas camadas de abstração que controlam diretamente o fluxo de execução. Parece contrário ao que Rust é. O usuário deve ser capaz de rastrear totalmente o código e descobrir como tudo funciona e para onde vai a execução. Eles devem ser encorajados a hackear coisas e trapacear os sistemas, e se usarem Rust seguro, deve ser seguro. Isso não vai melhorar nada se perdermos o controle de baixo nível, e posso muito bem me limitar aos futuros brutos.

Acredito firmemente que Rust, a linguagem (não std / core ), deve fornecer abstrações e sintaxe apenas se forem impossíveis (ou altamente impraticáveis) de fazer pelos usuários ou std . Essa coisa toda assíncrona saiu do controle a esse respeito. Precisamos realmente de algo mais do que pin API e geradores em rustc ?

@novacrazy Geralmente concordo com o sentimento, mas não com a conclusão.

deve fornecer abstrações e sintaxe apenas se forem impossíveis (ou altamente impraticáveis) de fazer pelos usuários ou std.

Qual é a razão para ter for -loops na linguagem quando eles também poderiam ser uma macro que se transforma em loop com quebras. Qual é a razão de || closure quando poderia ser um traço dedicado e construtores de objeto. Por que introduzimos ? quando já tínhamos try!() . A razão pela qual discordo dessas perguntas e de suas conclusões é a consistência. O objetivo dessas abstrações não é apenas o comportamento que encapsulam, mas também a acessibilidade delas. for -substituição se divide em mutabilidade, caminho de código primário e legibilidade. || -a substituição se divide na verbosidade da declaração - semelhante a Futures atualmente. try!() decompõe-se na ordem esperada de expressões e composição.

Considere que async não é apenas o decorador de uma função, mas também existem outras idéias de fornecer padrões adicionais por aync-blocks e async || . Uma vez que se aplica a itens de idiomas diferentes, a usabilidade de uma macro parece subótima. Nem pensar na implementação se ela tiver que ser visível para o usuário.

O usuário deve ser capaz de rastrear totalmente o código e descobrir como tudo funciona e para onde vai a execução. Eles devem ser encorajados a hackear coisas e trapacear os sistemas, e se usarem Rust seguro, deve ser seguro.

Não acho que esse argumento se aplique porque implementar co-rotinas usando inteiramente std api provavelmente dependeria muito de unsafe . E então há o argumento inverso porque embora seja factível - e você não será interrompido mesmo se houver uma maneira sintática e semântica na linguagem de fazer isso - qualquer mudança terá um grande risco de quebrar as suposições feitas em unsafe -code. Eu defendo que o Rust não deveria dar a impressão de que está tentando oferecer uma interface padrão para a implementação de bits que não pretende estabilizar em breve, incluindo os internos dos Coroutines. Um análogo a isso seria extern "rust-call" que serve como a mágica atual para deixar claro que as chamadas de função não têm essa garantia. Podemos nunca querer realmente ter que return , mesmo que o destino das corrotinas cheias ainda esteja para ser decidido. Podemos querer conectar uma otimização mais profundamente no compilador.

À parte: Falando nisso, em teoria, uma ideia não tão séria, poderia a co-rotina esperar ser denotada como um hipotético extern "await-call" fn () -> T ? Se assim for, isso permitiria no prelúdio um

trait std::ops::Co<T> {
    extern "rust-await" fn await(self) -> T;
}

impl<T> Co<T> for Future<Output=T> { }

também conhecido como future.await() em itens documentados no espaço do usuário. Ou, por falar nisso, outra sintaxe de operador também poderia ser possível.

@HeroicKatora

Por que introduzimos ? quando já tínhamos try!()

Para ser justo, eu também era contra isso, embora tenha crescido em mim. Seria mais aceitável se Try algum dia fosse estabilizado, mas isso é outro tópico.

O problema com os exemplos de "açúcar" que você dá é que eles são muito, muito finos. Mesmo impl MyStruct é mais ou menos açúcar por impl <anonymous trait> for MyStruct . Esses são açúcares de qualidade de vida que adicionam zero despesas gerais.

Em contraste, geradores e funções assíncronas adicionam sobrecarga não totalmente insignificante e sobrecarga mental significativa. Os geradores, especificamente, são muito difíceis de implementar como um usuário e podem ser usados ​​de forma mais eficaz e fácil como parte da própria linguagem, enquanto o async pode ser implementado em cima disso com relativa facilidade.

O ponto sobre bloqueios ou fechamentos assíncronos é interessante, porém, e admito que uma palavra-chave seria mais útil lá, mas ainda me oponho à incapacidade de acessar itens de nível inferior, se necessário.

Idealmente, seria maravilhoso suportar a palavra - chave async e uma macro de atributo / procedural #[async] , com a primeira permitindo acesso de baixo nível ao gerador gerado (sem trocadilhos). Enquanto isso, yield deve ser permitido em blocos ou funções usando async como palavra-chave. Tenho certeza de que eles podem até compartilhar o código de implementação.

Quanto a await , se ambos os itens acima forem possíveis, poderíamos fazer algo semelhante e limitar a palavra-chave await a async funções / blocos de palavras-chave e usar algum tipo de await!() macro no #[async] funções.

Pseudo-código:

// imaginary generator syntax stolen from JavaScript
fn* my_generator() -> T {
    yield some_value;

    // explicit return statements are only included to 
    // make it clear the generator/async functions are finished.
    return another_value;
}

// `await` keyword would not be allowed here, but the `yield` keyword is
#[async]
fn* my_async_generator() -> Result<T, E> {
    let item = some_op().await!()?; // uses the `.await!()` macro
    // which would really just use `yield` internally, but with the pinning API

    yield future::ok(item.clone());

    return Ok(item);
}

// `yield` would not be allowed here, but the `await` keyword is.
async fn regular_async() -> Result<T, E> {
   let some_op = async || { /*...*/ };

   let item = some_op() await?;

   return Ok(item);
}

O melhor dos dois mundos.

Isso parece uma progressão mais natural de complexidade para apresentar ao usuário e pode ser usado de forma mais eficaz para mais aplicativos.

Lembre-se de que este problema é especificamente para discussão da sintaxe de await . Outras conversas sobre como async funções e blocos são implementados estão fora do escopo, exceto para o propósito de lembrar às pessoas que await! não é algo que você possa ou jamais será capaz de escrever no Rust linguagem superficial.

Eu gostaria de pesar especificamente os prós e os contras de todas as propostas de sintaxe pós-correção. Se uma das sintaxes se destaca com uma pequena quantidade de contras, talvez devêssemos ir em frente. Se nenhum, entretanto, seria melhor oferecer suporte a sintaxe delimitada por prefixo de sintaxe que seja compatível com uma pós-correção ainda a ser determinada, se necessário. Como o Postfix parece ser mais conciso para alguns membros, parece prático avaliá-los fortemente antes de passar para outros.

A comparação será syntax , example (o reqwest de @mehcode parece um benchmark do mundo real utilizável a este respeito), em seguida, uma tabela de ( concerns e resolution opcional await provavelmente parecerá estranha para novatos e usuários experientes, mas todos os listados atualmente a incluem.

Exemplo em uma sintaxe de prefixo apenas para referência, não use essa parte do ciclismo:

let sent = (await client.get("https://my_api").send())?;
let res: MyResponse = (await sent.json())?;

• Palavra-chave Postfix foo() await?
  
  
  
  • Exemplo: client.get("https://my_api").send() await?.json() await?
  
  
  • | Preocupação | Resolução |
    
    | - | - |
    
    | O encadeamento sem ? pode ser confuso ou não permitido | |
  
  
• Campo Postfix foo().await?
  
  
  
  • Exemplo: client.get("https://my_api").send().await?.json().await?
  
  
  • | Preocupação | Resolução |
    
    | - | - |
    
    | Parece um campo | |
  
  
• Método Postfix foo().await()?
  
  
  
  • Exemplo: client.get("https://my_api").send().await()?.json().await()?
  
  
  • | Preocupação | Resolução |
    
    | - | - |
    
    | Parece um método ou característica | Pode ser documentado como ops:: trait? |
    
    | Não é uma chamada de função | |
  
  
• Postfix chamada foo()(await)?
  
  
  
  • Exemplo: client.get("https://my_api").send()(await)?.json()(await)?
  
  
  • | Preocupação | Resolução |
    
    | - | - |
    
    | Pode ser confundido com o argumento real | palavra-chave + destaque + sem sobreposição |
  
  
• Macro Postfix foo().await!()?
  
  
  
  • Exemplo: client.get("https://my_api").send().await!()?.json().await!()?
  
  
  • | Preocupação | Resolução |
    
    | - | - |
    
    | Na verdade não será uma macro… | |
    
    | … Ou await não é mais uma palavra-chave | |
  
  

Um pensamento adicional sobre pós-correção vs. prefixo do ponto de vista de possivelmente incorporar geradores: considerando valores, yield e await ocupam dois tipos opostos de declarações. O primeiro fornece um valor de sua função para o exterior, o último aceita um valor.

Sidenote: Bem, Python tem geradores interativos onde yield pode retornar um valor. Simetricamente, as chamadas para esse gerador ou fluxo precisam de argumentos adicionais em uma configuração de tipo forte. Não vamos tentar generalizar muito, e veremos que o argumento provavelmente se transfere em qualquer um dos casos.

Então, eu argumento que não é natural que essas declarações devam ser semelhantes. Aqui, semelhante às expressões de atribuição, talvez devêssemos nos desviar de uma norma definida por outras linguagens quando essa norma é menos consistente e menos concisa para Rust. Conforme expresso em outro lugar, contanto que incluamos await e existam semelhanças com outras expressões com a mesma ordem de argumentos, não deve haver nenhum obstáculo importante para a transição até mesmo de outro modelo.

Já que implícito parece fora de questão.

Por usar async / await em outras línguas e olhar as opções aqui, nunca achei sintaticamente agradável encadear futuros.

Há uma variante não encadeada na mesa?

// TODO: Better variable names.
await response = client.get("https://my_api").send();
await response = response?.json();
await response = response?;

Eu meio que gosto disso, pois você poderia argumentar que é parte do padrão.

O problema de fazer esperar por uma ligação é que a história de erro não é nada agradável.

// Error comes _after_ future is awaited
let await res = client.get("http://my_api").send()?;

// Ok
let await res = client.get("http://my_api").send();
let res = res?;

Precisamos ter em mente que quase todos os futuros disponíveis na comunidade para aguardar são falíveis e devem ser combinados com ? .

Se realmente precisamos do açúcar da sintaxe:

await? response = client.get("https://my_api").send();
await? response = response.json();

Ambos await e await? precisariam ser adicionados como palavras-chave ou estendemos isso para let também, ou seja, let? result = 1.divide(0);

Considerando a frequência com que o encadeamento é usado no código Rust, concordo inteiramente que é importante que o encadeamento aguarda seja o mais claro possível para o leitor. No caso da variante postfix de await:

client.get("https://my_api").send().await()?.json().await()?;

Isso geralmente se comporta de forma semelhante a como eu espero que o código do Rust se comporte. Eu tenho um problema com o fato de que await() neste contexto parece apenas uma chamada de função, mas tem um comportamento mágico (semelhante a uma função não) no contexto da expressão.

A versão da macro postfix tornaria isso mais claro. As pessoas estão acostumadas com pontos de exclamação enferrujados que significam "tem magia aqui" e certamente tenho uma preferência por esta versão por esse motivo.

client.get("https://my_api").send().await!()?.json().await!()?;

Dito isso, vale a pena considerar que já temos try!(expr) na linguagem e foi nosso precursor de ? . Adicionar uma macro await!(expr) agora seria totalmente consistente com a forma como try!(expr) e ? foram introduzidos na linguagem.

Com a versão await!(expr) de await, temos a opção de migrar para uma macro postfix mais tarde ou adicionar um novo operador com o estilo ? forma que o encadeamento se torne fácil. Um exemplo semelhante a ? mas para esperar:

// Not proposing this syntax at the moment. Just an example.
let a = perform()^;

client.get("https://my_api").send()^?.json()^?;

Acho que devemos usar await!(expr) ou await!{expr} por enquanto, pois é muito razoável e pragmático. Podemos então planejar a migração para uma versão postfix de await (ou seja, .await! ou .await!() ) mais tarde se / uma vez que macros postfix se tornarem uma coisa. (Ou eventualmente seguir o caminho de adicionar um operador de estilo ? ... depois de muito andar de bicicleta sobre o assunto: P)

Para sua informação, a sintaxe do Scala não é Await.result porque é uma chamada de bloqueio. Os Futuros de Scala são mônadas e, portanto, usam chamadas de método normais ou a compreensão de for mônada:

for {
  result <- future.map(further_computation)
  a = result * 2
  _ <- future_fn2(result)
} yield 123

Como resultado dessa notação horrível, uma biblioteca chamada scala-async foi criada com a sintaxe que sou mais a favor, que é a seguinte:

import scala.concurrent.ExecutionContext.Implicits.global
import scala.async.Async.{async, await}

val future = async {
  val f1 = async { ...; true }
  val f2 = async { ...; 42 }
  if (await(f1)) await(f2) else 0
}

Isso reflete fortemente como eu gostaria que o código do Rust se parecesse, com o uso de delimitadores obrigatórios e, como tal, eu gostaria de concordar com os outros em manter a sintaxe atual de await!() . Early Rust era um símbolo pesado e foi afastado por um bom motivo, eu presumo. O uso de açúcar sintático na forma de um operador postfix (ou o que quer que seja) é, como sempre, compatível com versões anteriores, e a clareza de await!(future) é inequívoca. Ele também reflete a progressão que tivemos com try! , conforme mencionado anteriormente.

Um benefício de mantê-lo como uma macro é que fica mais imediatamente óbvio que se trata de um recurso de linguagem em vez de uma chamada de função normal. Sem a adição de ! , o destaque de sintaxe do editor / visualizador seria a melhor maneira de detectar as chamadas, e acho que confiar nessas implementações é uma escolha mais fraca.

Meus dois centavos (não sou um contribuidor regular, fwiw) Tenho a maior preferência por copiar o modelo de try! . Isso já foi feito uma vez antes, funcionou bem e depois que se tornou muito popular, havia usuários suficientes para considerar um operador postfix.

Então, meu voto seria: estabilizar com await!(...) e punt em um operador postfix para um bom encadeamento baseado em uma enquete de desenvolvedores do Rust. Esperar é uma palavra-chave, mas ! indica que é algo "mágico" para mim e os parênteses não deixam nada ambíguo.

Também uma comparação:

| Postfix | Expression |
| --- | --- |
| .await | client.get("https://my_api").send().await?.json().await? |
| .await! | client.get("https://my_api").send().await!?.json().await!? |
| .await() | client.get("https://my_api").send().await()?.json().await()? |
| ^ | client.get("https://my_api").send()^?.json()^? |
| # | client.get("https://my_api").send()#?.json()#? |
| @ | client.get("https://my_api").send()@?.json()@? |
| $ | client.get("https://my_api").send()$?.json()$? |

Meu terceiro centavo é que gosto de @ (para "await") e # (para representar multi-threading / simultaneidade).

Também gosto do postfix @ ! Acho que não é uma opção ruim, embora pareça haver algum sentimento de que não é viável.

• _ @ for await_ é um mnemônico agradável e fácil de lembrar
• ? e @ seriam muito semelhantes, portanto, aprender @ depois de aprender ? não deveria ser um salto tão grande
• Ele ajuda a examinar uma cadeia de expressões da esquerda para a direita, sem ter que avançar para encontrar um delimitador de fechamento para entender uma expressão

Sou totalmente a favor da sintaxe await? foo e acho que é semelhante a alguma sintaxe vista em matemática, onde, por exemplo, sin² x pode ser usado para significar (sin x) ². Parece um pouco estranho no início, mas acho que é muito fácil de se acostumar.

Como disse acima, sou favorável em adicionar await!() como uma macro, assim como try!() , por agora e, eventualmente, decidir como pós-corrigir. Se pudermos manter em mente o suporte para um rustfix que converte automaticamente await!() chamadas para o postfix await que ainda está para ser decidido, melhor ainda.

A opção de palavra-chave postfix é uma clara vencedora para mim.

• Não há problema de precedência / ordem, mas a ordem ainda pode ser explicitada com parênteses. Mas principalmente não há necessidade de aninhamento excessivo (argumento semelhante para preferir o postfix '?' Em vez de 'try ()!').

• Parece bom com o encadeamento de várias linhas (consulte o comentário anterior de @earthengine) e, novamente, não há confusão sobre o pedido ou o que está sendo esperado. E nenhum aninhamento / parênteses extras para expressões com vários usos de await:

let x = x.do_something() await
         .do_another_thing() await;
let x = x.foo(|| ...)
         .bar(|| ...)
         .baz() await;

• Ele se presta a uma macro await! () Simples (consulte o comentário anterior de @novacrazy):

macro_rules! await {
    ($e:expr) => {{$e await}}
}

• Mesmo de linha única, simples (sem o '?'), Postfix await keyword chaining não me incomoda porque lê da esquerda para a direita e estamos aguardando o retorno de um valor que o método subsequente opera (embora eu apenas prefira código rustfmt'ed multilinha). O espaço quebra a linha e é suficiente como um indicador visual / dica de que a espera está acontecendo:

client.get("https://my_api").send() await.unwrap().json() await.unwrap()

Para sugerir outro candidato que eu ainda não vi (talvez porque não seria analisável), que tal um operador pós-fixado divertido de ponto duplo '..'? Isso me lembra que estamos esperando por algo (o resultado!) ...

client.get("https://my_api").send()..?.json()..?

Também gosto do postfix @ ! Acho que não é uma opção ruim, embora pareça haver algum sentimento de que não é viável.

• _ @ for await_ é um mnemônico agradável e fácil de lembrar
• ? e @ seriam muito semelhantes, portanto, aprender @ depois de aprender ? não deveria ser um salto tão grande
• Ele ajuda a examinar uma cadeia de expressões da esquerda para a direita, sem ter que avançar para encontrar um delimitador de fechamento para entender uma expressão

Não sou fã de usar @ for await. É estranho digitar em um teclado de layout fin / swe, pois tenho que pressionar alt-gr com meu polegar direito e, em seguida, pressionar a tecla 2 na linha de números. Além disso, @ tem um significado bem estabelecido (at), então não vejo por que devemos confundir o significado dele.

Prefiro simplesmente digitar await , é mais rápido, pois não requer nenhuma acrobacia de teclado.

Aqui está minha própria avaliação, muito subjetiva. Também adicionei future@await , o que me parece interessante.

| sintaxe | notas |
| --- | --- |
| await { f } | Forte:

• muito direto
• paralela for , loop , async etc.

• muito prolixo (5 letras, 2 colchetes, 3 opcionais, mas provavelmente espaços linted)
• o encadeamento resulta em muitas chaves aninhadas ( await { await { foo() }?.bar() }? )

• compara await sintaxe de Python, JS, C # e Dart
• direto, curto
• tanto a precedência útil quanto a precedência óbvia se comportam bem com ? ( await fut? vs. await? fut )

• ambíguo: precedência útil vs. óbvia deve ser aprendida
• o encadeamento também é muito complicado ( await (await foo()?).bar()? vs. await? (await? foo()).bar() )

• permite um encadeamento muito fácil
• baixo
• bom completamento de código

• engana os usuários fazendo-os pensar que é um campo / função / macro definido em algum lugar. Edit: Eu concordo com @jplatte que await!() parece menos mágico

• permite um encadeamento muito fácil
• baixo

• engana os usuários fazendo-os pensar que há uma variável await definida em algum lugar e que os futuros podem ser chamados como uma função

• permite um encadeamento muito fácil
• baixo

• não se compara a nada na sintaxe de Rust, não é óbvio
• meu cérebro agrupa client.get("https://my_api").send() await.unwrap().json() await.unwrap() em client.get("https://my_api").send() , await.unwrap().json() e await.unwrap() (agrupados por primeiro, depois . ) o que não é correto
• para Haskellers: parece currying, mas não é

• permite um encadeamento muito fácil
• muito curto

• parece um pouco estranho (pelo menos no início)
• consome @ que pode ser mais adequado para outra coisa
• pode ser fácil de ignorar, especialmente em grandes expressões
• usa @ de uma maneira diferente de todos os outros idiomas

• permite um encadeamento muito fácil
• baixo
• bom completamento de código
• await não precisa se tornar uma palavra-chave
• compatível com forwards: permite que novos operadores Postfix sejam adicionados na forma @operator . Por exemplo, ? poderia ter sido feito como @try .
• meu cérebro agrupa client.get("https://my_api").send()@await.unwrap().json()@await.unwrap() nos grupos corretos (agrupados por . primeiro, depois @ )

• usa @ de uma maneira diferente de todos os outros idiomas
• pode incentivar a adição de muitos operadores postfix desnecessários

Minhas pontuações:

• familiaridade (fam): quão próxima esta sintaxe é de sintaxes conhecidas (Rust e outras, como Python, JS, C #)
• obviedade (obv): Se você lesse isso no código de outra pessoa pela primeira vez, seria capaz de adivinhar o significado, a precedência, etc.?
• verbosidade (vrb): quantos caracteres são necessários para escrever
• visibilidade (vis): quão fácil é identificar (em vez de ignorar) no código
• encadeamento (cha): como é fácil encadear com . e outros await s
• agrupamento (grp): se meu cérebro agrupa o código nas partes corretas
• compatibilidade com versões futuras (fwd): se isso permite ser ajustado posteriormente de uma maneira ininterrupta

| sintaxe | fam | obv | vrb | vis | cha | grp | fwd |
| --------------------- | ----- | ----- | ----- | ----- | --- - | ----- | ----- |
| await!(fut) | ++ | + | - | ++ | - | 0 | ++ |
| await { fut } | ++ | ++ | - | ++ | - | 0 | + |
| await fut | ++ | - | + | ++ | - | 0 | - |
| fut.await | 0 | - | + | ++ | ++ | + | - |
| fut.await() | 0 | - | - | ++ | ++ | + | - |
| fut.await!() | 0 | 0 | - | ++ | ++ | + | - |
| fut(await) | - | - | 0 | ++ | ++ | + | - |
| fut await | - | - | + | ++ | ++ | - | - |
| fut@ | - | - | ++ | - | ++ | ++ | - |
| fut@await | - | 0 | + | ++ | ++ | ++ | 0 |

Parece-me que deveríamos espelhar a sintaxe try!() no primeiro corte e obter algum uso real do uso de await!(expr) antes de introduzir alguma outra sintaxe.

No entanto, se / quando construirmos uma sintaxe alternativa ..

Eu acho que @ parece feio, "at" para "async" não parece tão intuitivo para mim, e o símbolo já é usado para correspondência de padrões.

async prefixo ? (o que será freqüentemente).

Postfix .await!() chains muito bem, parece imediatamente óbvio em seu significado, inclui o ! para me dizer que vai fazer mágica e é menos inovador sintaticamente, portanto, o "próximo corte" se aproxima. pessoalmente favoreceria este. Dito isso, para mim, resta saber o quanto isso melhoraria o código real em relação ao primeiro corte await! (expr) .

Eu prefiro o operador de prefixo para casos simples:
let result = await task;
Parece muito mais natural levando em conta que não escrevemos o tipo de resultado, então o await ajuda mentalmente ao ler da esquerda para a direita para entender que o resultado é uma tarefa com o await.
Imagine assim:
let result = somehowkindoflongtask await;
até que você não chegue ao fim da tarefa, você não percebe que o tipo que ele retorna tem que ser aguardado. Lembre-se também (embora isso esteja sujeito a alterações e não diretamente vinculado ao futuro da linguagem) que IDEs como Intellij inline o tipo (sem qualquer personalização, se isso for possível) entre o nome e os iguais.
Imagine assim:

Isso não significa que minha opinião seja cem por cento voltada para o prefixo. Eu prefiro muito a versão pós-fixada do futuro quando os resultados estão envolvidos, pois parece muito mais natural. Sem qualquer contexto, posso facilmente dizer o que significa o quê:
future await?
future? await
Em vez disso, olhe para este, qual dos dois é verdadeiro, do ponto de vista de um novato:
await future? === await (future?)
await future? === (await future)?

Sou a favor da palavra-chave de prefixo: await future .

É o usado pela maioria das linguagens de programação que possuem async / await e, portanto, é imediatamente familiar para quem conhece um deles.

Quanto à precedência de await future? , qual é o caso comum?

• Uma função retornando um Result<Future> que deve ser aguardado.
• Um futuro que deve ser aguardado que retorna Result : Future<Result> .

Acho que o segundo caso é muito mais comum ao lidar com cenários típicos, uma vez que as operações de E / S podem falhar. Portanto:

await future? <=> (await future)?

No primeiro caso menos comum, é aceitável ter parênteses: await (future?) . Isso poderia até ser um bom uso para a macro try! se ela não tivesse sido descontinuada: await try!(future) . Dessa forma, o await e o operador do ponto de interrogação não estão em lados diferentes do futuro.

Por que não tomar await como o primeiro async parâmetro de função?

async fn await_chain() -> Result<usize, Error> {
    let _ = partial_computation(await)
        .unwrap_or_else(or_recover)
        .run(await)?;
}

client.get("https://my_api")
    .send(await)?
    .json(await)?

let output = future
    .run(await);

Aqui future.run(await) é uma alternativa a await future .
Poderia ser apenas a função async normal que leva o futuro e simplesmente executa a macro await!() nela.

C ++ (TR de simultaneidade)

auto result = co_await task;

Isso está no TS das corrotinas, não na simultaneidade.

Outra opção poderia ser usar a palavra-chave become vez de await :

async fn become_chain() -> Result<usize, Error> {
    let _ = partial_computation_future(become)
        .unwrap_or_else(or_recover_future)
        .start(become)?;
}

client.get("https://my_api")
    .send_future(become)?
    .json_future(become)?

let output = future.start(become);

become poderia ser uma palavra-chave para TCO garantido embora

Obrigado @EyeOfPython por essa [visão geral]. Isso é especialmente útil para as pessoas que estão entrando no depósito de bicicletas agora mesmo.

Pessoalmente, espero que fiquemos longe de f await , só porque é uma sintaxe nada rústica e faz com que pareça especial e mágica. Seria uma dessas coisas que os usuários novos no Rust ficarão confusos e acho que não acrescenta muita clareza, mesmo para veteranos do Rust, para valer a pena.

@novacrazy, o problema com este argumento é que qualquer macro await! _seria_ mágica, está executando uma operação que não é possível no código escrito pelo usuário

@ Nemo157 Concordo que uma macro await! seria mágica, mas eu diria que isso não é um problema. Já existem várias macros em std , por exemplo, compile_error! e não vi ninguém reclamar delas. Acho que é normal usar uma macro apenas para entender o que ela faz, não como faz.

Concordo com comentários anteriores que postfix seria o mais ergonômico, mas prefiro começar com prefix-macro await!(expr) e, potencialmente, fazer a transição para postfix-macro, uma vez que é uma coisa em vez de expr.await (campo integrado do compilador mágico) ou expr.await() (método integrado do compilador mágico). Ambos introduziriam uma sintaxe completamente nova puramente para este recurso, e IMO que apenas faz a linguagem parecer inconsistente.

@EyeOfPython Importa-se de adicionar future(await) às suas listas e tabela? Todos os aspectos positivos da sua avaliação de future.await() parecem se transferir sem a fraqueza

Já que alguns argumentaram que, apesar do destaque de sintaxe, foo.await parece muito com um acesso de campo, poderíamos mudar o token . para # e escrever foo#await . Por exemplo:

let foo = alpha()#await?
    .beta#await
    .some_other_stuff()#await?
    .even_more_stuff()#await
    .stuff_and_stuff();

Para ilustrar como o GitHub renderizaria isso com destaque de sintaxe, vamos substituir await por match pois eles têm o mesmo comprimento:

let foo = alpha()#match?
    .beta#match
    .some_other_stuff()#match?
    .even_more_stuff()#match
    .stuff_and_stuff();

Isso parece claro e ergonômico.

A justificativa para # vez de algum outro token não é específica, mas o token é bastante visível, o que ajuda.

Então, outro conceito: se futuro fosse referência :

async fn log_service(&self) -> T {
   let service = self.myService.foo(); // Only construction
   *self.logger.log("beginning service call");
   let output = *service.exec(); // Actually wait for its result
   *self.logger.log("foo executed with result {}.", output);
   output
}

async fn try_log(message: String) -> Result<usize, Error> {
    let logger = *acquire_lock();
    // Very terse, construct the future, wait on it, branch on its result.
    let length = (*logger.log_into(message))?;
    *logger.timestamp();
    Ok(length)
}

async fn await_chain() -> Result<usize, Error> {
    *(*partial_computation()).unwrap_or_else(or_recover);
}

(*(*client.get("https://my_api").send())?.json())?

let output = *future;

Isso seria muito feio e inconsistente. Deixe pelo menos remover a ambiguidade dessa sintaxe:

async fn log_service(&self) -> T {
   let service = self.myService.foo(); // Only construction
   $self.logger.log("beginning service call");
   let output = $service.exec(); // Actually wait for its result
   $self.logger.log("foo executed with result {}.", output);
   output
}

async fn try_log(message: String) -> Result<usize, Error> {
    let logger = $acquire_lock();
    // Very terse, construct the future, wait on it, branch on its result.
    let length = ($logger.log_into(message))?;
    $logger.timestamp();
    Ok(length)
}

async fn await_chain() -> Result<usize, Error> {
    $($partial_computation()).unwrap_or_else(or_recover);
}

($($client.get("https://my_api").send())?.json())?

let output = $future;

Melhor, mas ainda feio (e ainda pior, torna o realce de sintaxe do github). No entanto, para lidar com isso, vamos introduzir a capacidade de atrasar o operador de prefixo :

async fn log_service(&self) -> T {
   let service = self.myService.foo(); // Only construction
   self.logger.$log("beginning service call");
   let output = service.$exec(); // Actually wait for its result
   self.logger.$log("foo executed with result {}.", output);
   output
}

async fn try_log(message: String) -> Result<usize, Error> {
    let logger = $acquire_lock();
    // Very terse, construct the future, wait on it, branch on its result.
    let length = logger.$log_into(message)?;
    logger.$timestamp();
    Ok(length)
}

async fn await_chain() -> Result<usize, Error> {
    ($partial_computation()).$unwrap_or_else(or_recover);
}

client.get("https://my_api").$send()?.$json()?

let output = $future;

É exatamente isso que eu quero! Não apenas para await ( $ ), mas também para deref ( * ) e negate ( ! ).

Algumas advertências nesta sintaxe:

1. Precedência de operador: para mim é óbvio, mas para outros usuários?
2. Interoperabilidade das macros: o símbolo $ causaria problemas aqui?
3. Inconsistência de expressão: o operador de prefixo à esquerda aplica-se a toda a expressão, enquanto o operador de prefixo . ( await_chain fn demonstra isso), é confuso?
4. Análise e implementação: essa sintaxe é válida?

@Centril
IMO # está muito próximo da sintaxe literal bruta r#"A String with "quotes""#

IMO # está muito próximo da sintaxe literal bruta r#"A String with "quotes""#

Parece bastante claro a partir do contexto qual é a diferença neste caso.

@Centril
Sim, mas a sintaxe também é muito estranha ao estilo que Rust usa IMHO. Não se assemelha a nenhuma sintaxe existente com uma função semelhante.

@Laaas Nem ? quando foi introduzido. Eu ficaria feliz em ir com .await ; mas outros parecem insatisfeitos com isso, então estou tentando encontrar algo que funcione (ou seja, seja claro, ergonômico, suficientemente fácil de digitar, encadeado, tenha boa precedência) e foo#await parece satisfazer tudo isso.

? tem vários outros pontos positivos, enquanto #await parece bastante arbitrário. Em qualquer caso, se você quiser algo como .await , por que não .await! ?

@Centril Essa era a principal razão por trás de future(await) , para evitar o acesso ao campo sem ter que adicionar nenhum operador extra ou sintaxe estrangeira.

enquanto #await parece bastante arbitrário.

# é arbitrário, sim - isso é tudo ou nada? Quando uma nova sintaxe é inventada em algum ponto, ela deve ser arbitrária porque alguém achou que parecia boa ou fazia sentido.

por que não .await! ?

Isso é igualmente arbitrário, mas não tenho nenhuma oposição a isso.

@Centril Essa era a principal razão por trás de future(await) , para evitar o acesso ao campo sem ter que adicionar nenhum operador extra ou sintaxe estrangeira.

Em vez disso, parece um aplicativo de função em que você está passando await para future ; isso me parece mais confuso do que "acesso de campo".

Em vez disso, parece um aplicativo de função de onde você está passando o Wait para o futuro; isso me parece mais confuso do que "acesso de campo".

Para mim, isso fazia parte da concisão. Await é em muitos aspectos como uma chamada de função (callee é executado entre você e seu resultado), e passar uma palavra-chave para essa função deixou claro que se trata de um tipo diferente de chamada. Mas vejo como pode ser confuso que a palavra-chave seja semelhante a qualquer outro argumento. (Menos destaque de sintaxe e mensagens de erro do compilador tentando reforçar essa mensagem. Futuros não podem ser chamados de outra forma senão sendo esperados e vice-versa).

@Centril

Ser arbitrário não é uma coisa negativa , mas ter semelhança com uma sintaxe existente é uma coisa positiva. .await! não é tão arbitrário, pois não é uma sintaxe inteiramente nova; afinal, é apenas uma macro pós-correção chamada await .

Para esclarecer / adicionar ao ponto sobre a nova sintaxe especificamente para await , o que quero dizer com isso é a introdução de uma nova sintaxe que é diferente da sintaxe existente. Existem muitas palavras-chave de prefixo, algumas das quais foram adicionadas após Rust 1.0 (por exemplo, union ), mas AFAIK não uma única palavra-chave postfix (não importa se separada por um espaço, um ponto ou outra coisa) . Eu também não consigo pensar em nenhuma outra linguagem que tenha palavras-chave Postfix.

IMHO, a única sintaxe pós-fixada que não aumenta significativamente a estranheza do Rust é a macro pós-fixada, porque ela espelha chamadas de método, mas pode ser claramente identificada como uma macro por qualquer pessoa que já tenha visto uma macro Rust antes.

Também gostei da macro await!() padrão. É muito claro e simples.
Eu prefiro um acesso semelhante a um campo (ou qualquer outro postfix) para coexistir como awaited .

• Await sente que você estará aguardando o que vem a seguir / certo. Esperado, ao que veio antes / partiu.
• Coerente com o método cloned() em iteradores.

E também gostei de @? como ? como açúcar.
Isso é pessoal, mas na verdade eu prefiro a combinação &? , porque @ tende a ser muito alto e ultrapassar a linha, o que causa muita distração. & também é alto (bom), mas não é inferior (também é bom). Infelizmente & já tem um significado, embora sempre seja seguido por ? .. Eu acho?

Por exemplo.

Lorem@?
  .ipsum@?
  .dolor()@?
  .sit()@?
  .amet@?
Lorem@?.ipsum@?.dolor()@?.sit()@?.amet@?

Lorem&?
  .ipsum&?
  .dolor()&?
  .sit()&?
  .amet&?
Lorem&?.ipsum&?.dolor()&?.sit()&?.amet&?

Para mim, o @ parece um personagem inchado, desvia o fluxo de leitura. Por outro lado, &? é agradável, não distrai (minha) leitura e tem um bom espaço superior entre & e ? .

Pessoalmente, acho que uma macro await! simples deve ser usada. Se macros pós-correção entrarem na linguagem, então a macro poderia simplesmente ser expandida, não?

@Laaas Por mais que eu gostaria que houvesse, ainda não há macros pós-fixadas no Rust, então elas são uma nova sintaxe. Observe também que foo.await!.bar e foo.await!().bar não têm a mesma sintaxe de superfície. No último caso, haveria um postfix real e uma macro embutida (o que implica desistir de await como palavra-chave).

@jplatte

Existem muitas palavras-chave de prefixo, algumas das quais foram adicionadas após Rust 1.0 (por exemplo, union ),

union não é um operador de expressão unário, portanto, é irrelevante nesta comparação. Existem exatamente 3 operadores de prefixo unário estáveis ​​em Rust ( return , break e continue ) e todos eles são digitados em ! .

Hmm ... Com @ minha proposta anterior parece um pouco melhor:

client.get("https://my_api").@send()?.@json()?

let output = @future;

let foo = (@alpha())?
    .<strong i="8">@beta</strong>
    .@some_other_stuff()?
    .@even_more_stuff()
    .stuff_and_stuff();

@Centril Esse é o meu ponto, uma vez que ainda não temos macros pós-correção, deveria ser simplesmente await!() . Também quis dizer .await!() FYI. Não acho que await precise ser uma palavra-chave, embora você possa reservá-la se achar que é problemática.

union não é um operador de expressão unário, portanto, é irrelevante nesta comparação. Existem exatamente 3 operadores de prefixo unário estáveis ​​em Rust ( return , break e continue ) e todos eles são digitados em ! .

Isso ainda significa que a variante prefixo-palavra-chave se encaixa no grupo de operadores de expressão unária, mesmo se digitada de forma diferente. A variante da palavra-chave postfix é uma divergência muito maior da sintaxe existente, uma que é muito grande em relação à importância de await na linguagem na minha opinião.

Com relação ao prefixo macro e possibilidade de transição para pós-correção: await precisa permanecer uma palavra-chave para que isso funcione. A macro seria então algum item de linguagem especial onde é permitido usar uma palavra-chave como o nome sem um r# extra, e r#await!() poderia, mas provavelmente não deveria, invocar a mesma macro. Fora isso, parece a solução mais pragmática para torná-lo disponível.

Isto é, mantenha await como uma palavra-chave, mas faça await! resolver para uma macro lang-item.

@HeroicKatora por que ela precisa permanecer como uma palavra-chave para funcionar?

@Laaas Porque se quisermos manter a possibilidade de transição aberta, precisamos permanecer abertos para uma futura sintaxe pós-correção que a use como uma palavra-chave. Portanto, precisamos manter a reserva de palavra-chave para que não precisemos de uma pausa de edição para a transição.

@Centril

Observe também que foo.await! .Bar e foo.await! (). Bar não são a mesma sintaxe de superfície. No último caso, haveria um postfix real e uma macro embutida (o que implica desistir de await como palavra-chave).

Isso não poderia ser resolvido fazendo a palavra-chave await combinada com ! resolver para uma macro interna (que não pode ser definida por meios normais)? Em seguida, ele permanece uma palavra-chave, mas resolve para uma macro na sintaxe de macro.

@HeroicKatora Por que await em x.await!() seria uma palavra-chave reservada?

Não seria, mas se mantivermos a pós-correção sem solução, não precisa ser a solução a que chegaremos em discussões posteriores. Se essa fosse a melhor possibilidade única acordada, então deveríamos adotar essa sintaxe exata pós-correção em primeiro lugar.

Esta é outra vez que encontramos algo que funciona muito melhor como um operador Postfix. O grande exemplo disso é try! qual eventualmente demos seu próprio símbolo ? . No entanto, acho que esta não é a última vez em que um operador Postfix é mais ideal e não podemos dar a tudo seu próprio caráter especial. Portanto, acho que não devemos pelo menos começar com @ . Seria muito melhor se tivéssemos uma maneira de fazer esse tipo de coisas. É por isso que apoio o estilo de macro Postfix .await!() .

let x = foo().try!();
let y = bar().await!();

Mas para que isso faça sentido, as próprias macros pós-fixadas teriam que ser introduzidas. Portanto, acho que seria melhor começar com uma sintaxe de macro await!(foo) normal. Poderíamos posteriormente expandir isso para foo.await!() ou até foo@ se realmente acharmos que isso é importante o suficiente para justificar seu próprio símbolo.
Que essa macro precise de um pouco de mágica não é novidade para std e para mim não é um grande problema.
Como @jplatte colocou:

@ Nemo157 Concordo que uma macro await! seria mágica, mas eu diria que isso não é um problema. Já existem várias macros em std , por exemplo, compile_error! e não vi ninguém reclamar delas. Acho que é normal usar uma macro apenas para entender o que ela faz, não como faz.

Um problema recorrente que vejo discutido aqui é sobre o encadeamento e como usar
aguardar em expressões de encadeamento. Talvez possa haver outra solução?

Se não quisermos usar o await para encadeamento e apenas usar o await para
atribuições, poderíamos ter algo como apenas substituir let por await:
await foo = future

Então, para o encadeamento, poderíamos imaginar algum tipo de operação como await res = fut1 -> fut2 ou await res = fut1 >>= fut2 .

O único caso que falta é esperar e retornar o resultado, algum atalho
por await res = fut; res .
Isso poderia ser feito facilmente com um simples await fut

Eu não acho que tenha visto outra proposta como esta (pelo menos para o
encadeamento), deixando isso aqui, pois acho que seria bom usar.

@HeroicKatora Eu adicionei fut(await) à lista e classifiquei de acordo com minha opinião.

Se alguém achar que minha pontuação está errada, por favor, me diga!

Em termos de sintaxe, acho que .await!() é limpo e permite o encadeamento, mas não adiciona estranhezas à sintaxe.

No entanto, se alguma vez obtivermos macros Postfix "reais", será um pouco estranho, porque presumivelmente .r#await!() poderia ser sombreado, enquanto .await!() não poderia.

Eu sou fortemente contra a opção de "palavra-chave postfix" (separada por um espaço como: foo() await?.bar() await? ), porque acho o fato de que await está unido à parte seguinte da expressão, e não a parte em que opera. Eu preferiria praticamente qualquer símbolo diferente de espaço em branco aqui, e até mesmo prefiro sintaxe de prefixo sobre isso, apesar de suas desvantagens com cadeias longas.

Eu acho que "precedência óbvia" (com o await? sugar) é claramente a melhor opção de prefixo, já que delimitadores obrigatórios são uma dor para o caso muito comum de esperar uma única instrução, e "precedência útil" não é intuitivo e, portanto, confuso.

Em termos de sintaxe, acho que .await!() é limpo e permite o encadeamento, mas não adiciona estranhezas à sintaxe.

No entanto, se alguma vez obtivermos macros Postfix "reais", será um pouco estranho, porque presumivelmente .r#await!() poderia ser sombreado, enquanto .await!() não poderia.

Se obtivermos macros postfix e usarmos .await!() , podemos cancelar a reserva de await como uma palavra-chave e apenas torná-la uma macro postfix. A implementação dessa macro ainda exigiria um pouco de magia, mas seria uma macro real, exatamente como compiler_error! é hoje.

@EyeOfPython Você poderia explicar em detalhes quais mudanças você considera em forward-compatibility ? Não tenho certeza de que maneira fut@await teria uma classificação superior a fut.await!() e await { future } inferior a await!(future) . A coluna verbosity também parece um pouco estranha, algumas expressões são curtas, mas têm avaliação inferior, ela considera declarações encadeadas, etc. Todo o resto parece equilibrado e como a avaliação extensiva mais bem condensada até agora.

Depois de ler esta discussão, parece que muitas pessoas querem adicionar uma macro await!() normal e descobrir a versão postfix mais tarde. Isso pressupõe que realmente queremos uma versão pós-fixada, o que considerarei verdadeiro no restante deste comentário.

Portanto, gostaria apenas de pesquisar a opinião de todos aqui: Devemos todos concordar com a sintaxe await!(future) POR AGORA? Os prós são que não há ambigüidade de análise com essa sintaxe, e também é uma macro, portanto, nenhuma alteração da sintaxe da linguagem para oferecer suporte a essa alteração. Os contras são que ficará feio para o encadeamento, mas isso não importa, pois essa sintaxe pode ser facilmente substituída por uma versão postfix automaticamente.

Depois de estabelecermos isso e implementá-lo na linguagem, podemos continuar a discussão sobre a sintaxe do postfix await com experiências, ideias e possivelmente outros recursos do compilador mais maduros.

@HeroicKatora Eu await para ser usado como identificador comum naturalmente e permitiria que outros operadores postfix fossem adicionados, enquanto eu acho que fut.await!() seria melhor se await foi reservado. No entanto, não tenho certeza se isso é razoável, também parece definitivamente válido que fut.await!() possa ser mais alto.

Para await { future } vs await!(future) , o último mantém a opção aberta para mudar para quase qualquer uma das outras opções, enquanto o primeiro apenas permite qualquer uma das variantes await future ( conforme descrito na entrada do blog @withoutboats ). Portanto, acho que definitivamente deveria ser fwd(await { future }) < fwd(await!(future)) .

Quanto à verbosidade, você está correto, após dividir os casos em subgrupos não reavaliei a verbosidade, que deve ser a mais objetiva de todas.

Vou editá-lo para levar em consideração seus comentários, obrigado!

Estabilizar await!(future) é a pior opção que posso imaginar:

1. Isso significa que temos que cancelar a reserva de await que significa que o design da linguagem futura ficará mais difícil.
2. Ele está conscientemente tomando o mesmo caminho de try!(result) que suspendemos (e que requer a gravação de r#try!(result) no Rust 2018).
   
   
   
   • Se soubermos que await!(future) é uma sintaxe incorreta que pretendemos descontinuar, isso estará criando deliberadamente uma dívida técnica.
   
   
   • Além disso, try!(..) é definido em Rust, enquanto await!(future) não pode ser e, em vez disso, seria a mágica do compilador.
   
   
   • Reprovar try!(..) não foi fácil e teve um impacto social. Passar por aquela provação novamente não parece atraente.
   
   
3. Isso usaria sintaxe macro para uma parte central e importante da linguagem; isso não parece claramente de primeira classe.
4. await!(future) é barulhento ; ao contrário de await future você precisa escrever !( ... ) .
5. APIs Rust, e especialmente a biblioteca padrão, são centradas em torno da sintaxe de chamada de método. Por exemplo, é comum encadear métodos ao lidar com Iterator s. Semelhante a await { future } e await future , a sintaxe await!(future) tornará o encadeamento de métodos difícil e induzirá ligações temporárias de let . Isso é ruim para a ergonomia e, na minha opinião, para a legibilidade.

Eu gostaria de concordar com @Centril, mas há algumas questões em aberto. Tem certeza sobre 1. ? Se o tornássemos 'mágico', não poderíamos torná-lo ainda mais mágico permitindo que isso se referisse a uma macro sem descartá-la como uma palavra-chave?

Entrei para Rust tarde demais para avaliar a perspectiva social de 2. . Repetir um erro não parece atraente, mas como alguns códigos ainda não foram convertidos de try! , deve ficar evidente que foi uma solução. Isso levanta a questão de saber se pretendemos ter async/await como um incentivo para migrar para a edição 2018 ou, se preferir, seja paciente e não repita isso.

Dois outros recursos centrais (imho) muito semelhantes a 3. : vec![] e format! / println! . O primeiro porque não existe uma construção estável em caixa, o último devido à construção da string de formato e por não ter expressões digitadas de forma dependente. Acho que essas comparações também colocam parcialmente 4. em outra perspectiva.

Eu me oponho a qualquer sintaxe que não seja parecida com o inglês. Ou seja, "await x" significa algo como inglês. "x # !! @! &" não. "x.await" tem uma leitura tentadora como o inglês, mas não será quando x for uma linha não trivial, como uma chamada de função de membro com nomes longos ou um monte de métodos iteradores encadeados etc.

Mais especificamente, eu apoio a "palavra-chave x", onde a palavra-chave é provavelmente await . Eu vim de usar as co-rotinas C ++ TS e as co-rotinas c # da unidade, que usam uma sintaxe muito semelhante a essa. E depois de anos usando-os no código de produção, minha crença é que saber onde estão seus pontos de rendimento, de relance, é absolutamente crítico . Quando você desliza para baixo na linha de recuo da sua função, você pode selecionar cada co_await / yield return em uma função de 200 linhas em questão de segundos, sem carga cognitiva.

O mesmo não é verdade para o operador ponto com await depois, ou alguma outra sintaxe pós-fixada de "pilha de símbolos".

Eu acredito que await é uma operação de fluxo de controle fundamental. Deve receber o mesmo nível de respeito que 'if , while , match e return . Imagine se qualquer um desses fossem operadores postfix - ler o código do Rust seria um pesadelo. Como com meu argumento para await, já que você pode deslizar rapidamente a linha de indentação de qualquer função Rust e selecionar imediatamente todo o fluxo de controle. Existem exceções, mas são exceções, e não é algo pelo qual devemos nos esforçar.

Eu concordo com @ejmahler. Não devemos esquecer do outro lado do desenvolvimento - a revisão do código. Arquivos com código-fonte são lidos com muito mais frequência do que escritos, portanto, acho que deveria ser mais fácil de ler e entender do que escrever. Encontrar os pontos de rendimento é muito importante na revisão do código. E eu pessoalmente votaria em Useful precedence .
Eu acredito que isso:

...
let response = await client.get("https://my_api").send()?;
let body: MyResponse = await response.into_json()?;

é mais fácil de entender do que isso:

...
let body: MyResponse = client.get("https://my_api").send().await?.into_json().await?;

@HeroicKatora

Eu gostaria de concordar com @Centril, mas há algumas questões em aberto. Tem certeza sobre 1. ? Se o tornássemos 'mágico', não poderíamos torná-lo ainda mais mágico permitindo que isso se referisse a uma macro sem descartá-la como uma palavra-chave?

Tecnicamente? Possivelmente. No entanto, deve haver uma forte justificativa para casos especiais e, neste caso, ter magia sobre magia não parece justificado.

Isso levanta a questão de saber se pretendemos ter async/await como um incentivo para migrar para a edição 2018 ou, se preferir, seja paciente e não repita isso.

Não sei se já dissemos que pretendíamos que o novo sistema de módulo, async / await , e try { .. } fossem incentivos; mas, independentemente de nossa intenção, eles são, e acho que isso é uma coisa boa. Queremos que as pessoas comecem a usar novos recursos de linguagem para escrever bibliotecas melhores e mais idiomáticas.

Dois outros recursos centrais (imho) muito semelhantes a 3. : vec![] e format! / println! . O primeiro porque não há um afaik de construção em caixa estável,

O primeiro existe e é escrito vec![1, 2, 3, ..] , para imitar expressões literais de array, por exemplo, [1, 2, 3, ..] .

@ejmahler

"x.await" tem uma leitura tentadora como o inglês, mas não será quando x for uma linha não trivial, como uma chamada de função de membro com nomes longos ou um monte de métodos iteradores encadeados etc.

O que há de errado com vários métodos iteradores encadeados? Isso é Rust claramente idiomático.
A ferramenta rustfmt também formatará cadeias de métodos em linhas diferentes para que você obtenha (novamente usando match para mostrar o realce de sintaxe):

let foo = alpha().match?  // or `alpha() match?`, `alpha()#match?`, `alpha().match!()?`
    .beta
    .some_other_stuff().match?
    .even_more_stuff().match
    .stuff_and_stuff();

Se você leu .await como "então espere", a leitura é perfeita, pelo menos para mim.

E depois de anos usando-os no código de produção, minha crença é que saber onde estão seus pontos de rendimento, de relance, é absolutamente crítico .

Não vejo como o postfix await nega isso, especialmente na formatação rustfmt acima. Além disso, você pode escrever:

let foo = alpha().match?;
let bar = foo.beta.some_other_stuff().match?;
let baz = bar..even_more_stuff().match;
let quux = baz.stuff_and_stuff();

se você gosta disso.

em uma função de 200 linhas em questão de segundos, sem carga cognitiva.

Sem saber muito sobre a função particular, parece-me que 200 LOC provavelmente viola o princípio de responsabilidade única e faz muito. A solução é fazer menos e dividir. Na verdade, acho que é o mais importante para a manutenção e a legibilidade.

Eu acredito que await é uma operação fundamental de controle de fluxo.

E também ? . Na verdade, await e ? são ambas operações de fluxo de controle eficazes que dizem "extrair valor fora do contexto". Em outras palavras, no contexto local, você pode imaginar esses operadores tendo o tipo await : impl Future<Output = T> -> T e ? : impl Try<Ok = T> -> T .

Existem exceções, mas são exceções, e não é algo pelo qual devemos nos esforçar.

E a exceção aqui é ? ?

@andreytkachenko

Eu concordo com @ejmahler. Não devemos esquecer do outro lado do desenvolvimento - a revisão do código. Arquivos com código-fonte são lidos com muito mais frequência do que escritos, portanto, acho que deveria ser mais fácil de ler e entender do que escrever.

A divergência é em torno do que seria melhor para legibilidade e ergonomia.

é mais fácil de entender do que isso:

...
let body: MyResponse = client.get("https://my_api").send().await?.into_json().await?;

Não é assim que seria formatado; executá-lo em rustfmt permite que você:

let body: MyResponse = client
    .get("https://my_api")
    .send()
    .match?
    .into_json()
    .match?;

@ejmahler @andreytkachenko Eu concordo com o @Centril aqui, a maior mudança (alguns podem dizer melhoria, eu não) que você ganha com a sintaxe do prefixo é que os usuários são incentivados a dividir suas declarações em várias linhas porque todo o resto é ilegível. Isso não é Rust-y e as regras de formatação usuais compensam isso na sintaxe pós-correção. Eu também considero o ponto de rendimento mais obscuro na sintaxe do prefixo porque await não é realmente colocado no ponto de código onde você produz, em vez de se opor a ele.

Se você seguir este caminho, vamos experimentar para soletrar, em vez de await como um substituto para let no espírito da ideia de

await? response = client.get("https://my_api").send();
await? body: MyResponse = response.into_json();

Mas para nenhum desses eu vejo benefício suficiente para explicar sua perda de composibilidade e complicações na gramática.

Hm ... é desejável ter uma forma de prefixo e sufixo de await? Ou apenas a forma de sufixo?

Encadear chamadas de método é idiomático especificamente quando se fala sobre
iteradores e, em muito menos opções, mas, fora isso, a ferrugem é
uma linguagem imperativa primeiro e uma linguagem funcional depois.

Não estou argumentando que um postfix é literalmente incompreensível, estou fazendo um
argumento de carga cognitiva que esconde uma operação de fluxo de controle de nível superior,
carregando a mesma importância que 'retornar', aumenta a carga cognitiva quando
em comparação a colocá-lo o mais próximo possível do início da linha - e estou
fazendo esse argumento com base em anos de experiência em produção.

No sábado, 19 de janeiro de 2019 às 11h59 Mazdak Farrokhzad [email protected]
escrevi:

@HeroicKatora https://github.com/HeroicKatora

@Centril https://github.com/Centril Eu gostaria de concordar, mas existem
algumas questões abertas. Você tem certeza sobre 1.? Se fizermos isso, 'mágica' poderia
não tornamos isso ainda mais mágico ao permitir que isso se refira a uma macro sem
descartando-o como uma palavra-chave?

Tecnicamente? Possivelmente. No entanto, deve haver uma forte justificativa para
casos especiais e, neste caso, ter magia sobre magia não parece
justificado.

Isso levanta a questão de saber se pretendemos ter assíncrono / aguardar como
um incentivo para migrar para a edição 2018 ou melhor, seja paciente e não
repita isso.

Não sei se alguma vez dissemos que pretendíamos um novo sistema de módulo, async /
espere, e tente {..} ser incentivos; mas independentemente da nossa intenção
eles são, e eu acho que isso é uma coisa boa. Queremos que as pessoas eventualmente
comece a usar novos recursos de linguagem para escrever melhor e mais idiomático
bibliotecas.

Dois outros recursos centrais (imho) muito parecidos com 3 .: vec! [] E formato! /
println !. O primeiro muito porque não há estábulo encaixotado
afaik de construção,

O primeiro existe e é escrito vec! [1, 2, 3, ..], para imitar a matriz
expressões literais, por exemplo [1, 2, 3, ..].

@ejmahler https://github.com/ejmahler

"x.await" tem uma leitura tentadoramente semelhante ao inglês, mas não será quando x for um
linha não trivial, como uma chamada de função de membro com nomes longos ou um monte
de métodos iteradores encadeados, etc.

O que há de errado com vários métodos iteradores encadeados? Isso é distintamente
Rust idiomática.
A ferramenta rustfmt também formatará cadeias de métodos em linhas diferentes para que você
get (novamente usando match para mostrar o realce de sintaxe):

deixe foo = alpha (). corresponder? // ou alpha() match? , alpha()#match? , alpha().match!()?
.beta
.some_other_stuff (). match?
.even_more_stuff (). match
.stuff_and_stuff ();

Se você ler .await como "then Wait", é perfeito, pelo menos para mim.

E depois de anos usando-os no código de produção, minha convicção é que saberonde seus pontos de rendimento estão, à primeira vista, é absolutamente crítico .

Não vejo como o postfix await nega isso, especialmente no rustfmt
formatação acima. Além disso, você pode escrever:

deixe foo = alpha (). corresponder?; deixe bar = foo.beta.some_other_stuff (). match?; deixe baz = bar..even_more_stuff (). match; deixe quux = baz.stuff_and_stuff ();

se você gosta disso.

em uma função de 200 linhas em questão de segundos, sem carga cognitiva.

Sem saber muito sobre a função particular, parece-me
que 200 LOC provavelmente viola o princípio de responsabilidade única e faz
demais. A solução é fazer menos e dividir. Na verdade, eu
acho que é a coisa mais importante para manutenção e legibilidade.

Acredito que esperar é uma operação fundamental de controle de fluxo.

Então é? Na verdade, espera e? são ambas operações de controle de fluxo eficazes
que dizem "extrair valor fora do contexto". Em outras palavras, no local
contexto, você pode imaginar esses operadores tendo o tipo await: impl
Futuro

-> T e? : impl Try-> T.

Existem exceções, mas são exceções e não devemos
se esforçar.

E a exceção aqui é? ?

@andreytkachenko https://github.com/andreytkachenko

Eu concordo com @ejmahler https://github.com/ejmahler . Nós não deveriamos
esqueça o outro lado do desenvolvimento - revisão de código. Arquivo com código-fonte é
sendo lido com muito mais frequência do que escrito, portanto, acho que deveria ser mais fácil
leia-e-entenda então para escrever.

A discordância é sobre o que seria melhor para legibilidade e
ergonomia.

é mais fácil de entender do que isso:

... let body: MyResponse = client.get ("https: // my_api") .send (). await? .into_json (). await ?;

Não é assim que seria formatado; a formatação idiomática rustfmt
é:

let body: MyResponse = client
.get ("https: // my_api")
.enviar()
.partida?
.into_json ()
.partida?;

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/rust-lang/rust/issues/57640#issuecomment-455810497 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ABGmeocFJpPKaypvQHo9LpAniGOUFrmzks5vE3kXgaJpZM4aBlba
.

@ejmahler Discordamos re. "se escondendo"; os mesmos argumentos foram feitos errados.

O operador ? é muito baixo e foi criticado no passado por "esconder" um retorno. Na maioria das vezes, o código é lido, não escrito. Renomeá-lo para ?! o tornará duas vezes mais longo e, portanto, mais difícil de ignorar.

No entanto, finalmente estabilizamos ? e, desde então, acho que a profecia não se concretizou.
Para mim, o postfix await segue a ordem natural de leitura (pelo menos para falantes da esquerda para a direita). Em particular, segue a ordem do fluxo de dados.

Para não mencionar o realce de sintaxe: qualquer coisa relacionada à espera pode ser realçada com uma cor brilhante, para que possam ser encontrados rapidamente. Portanto, mesmo se tivéssemos um símbolo em vez da palavra await real, ele ainda seria muito legível e localizável no código destacado pela sintaxe. Dito isso, eu ainda prefiro usar a palavra await apenas por motivos de grep - é mais fácil fazer o grep do código para qualquer coisa que esteja sendo aguardada se usarmos apenas a palavra await vez de um símbolo como @ ou #, cujo significado depende da gramática.

vocês, isso não é ciência de foguetes

let body: MyResponse = client.get("https://my_api").send()...?.into_json()...?;

O postfix ... é extremamente legível, difícil de perder à primeira vista e super intuitivo, já que você o lê naturalmente como o código que vai perdendo o controle enquanto espera que o resultado do futuro esteja disponível. sem necessidade de precedência / macro shenanigans e nenhum ruído de linha extra de sigilos desconhecidos, uma vez que todo mundo já viu elipses antes.

(desculpas a @solson)

@ ben0x539 Isso significa que posso acessar um membro do meu resultado como future()....start ? Ou aguardar um resultado de intervalo como range()..... ? E como exatamente você quer dizer no precedence/macro shenanigans necessary and já que atualmente as reticências .. exigem ser um operador binário ou parêntese à direita e isso é terrivelmente próximo à primeira vista.

Sim o ? Operador existe. Eu já reconheci que havia
exceções. Mas é uma exceção. A grande maioria do fluxo de controle em qualquer
O programa Rust acontece por meio de palavras-chave de prefixo.

Sábado, 19 de janeiro de 2019 às 13h51 Benjamin Herr [email protected]
escrevi:

vocês, isso não é ciência de foguetes

let body: MyResponse = client.get ("https: // my_api") .send () ...?. into_json () ...?;

Postfix ... é extremamente legível, difícil de perder à primeira vista e super
intuitivo, já que você o lê naturalmente como um tipo de código
enquanto espera que o resultado do futuro esteja disponível. não
precedência / travessuras macro necessárias e nenhum ruído de linha extra de
sigilos desconhecidos, já que todo mundo já viu elipses antes.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/rust-lang/rust/issues/57640#issuecomment-455818177 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ABGmen354fhk7snYsANTfp5oOuDb4OLYks5vE5NSgaJpZM4aBlba
.

@HeroicKatora Isso parece um pouco artificial, mas com certeza. Eu quis dizer que, como é uma operação postfix, como as outras soluções postfix sugeridas, evita a necessidade de precedência contra-intuitiva para await x? e não é uma macro.

@ejmahler

Sim o ? Operador existe. Já reconheci que havia exceções. Mas é uma exceção.

Existem duas formas de expressão que cabem em keyword expr , nomeadamente return expr e break expr . O primeiro é mais comum do que o último. A forma continue 'label realmente não conta porque, embora seja uma expressão, ela não tem a forma keyword expr . Então agora você tem 2 formas de expressão unária de palavra-chave com prefixo inteiro e 1 forma de expressão unária pós-fixada. Antes mesmo de levarmos em conta que ? e await são mais semelhantes do que await e return são, eu dificilmente chamaria return/break expr uma regra para ? ser uma exceção contra.

A grande maioria do fluxo de controle em qualquer programa Rust acontece por meio de palavras-chave de prefixo.

Como mencionado anteriormente, break expr não é tão comum ( break; é mais típico e return; são mais típicos e não são formas de expressão unárias). O que resta são os primeiros return expr; s e não me parece nada claro que isso é muito mais comum do que match , ? , apenas aninhado if let else s, e for loops. Assim que try { .. } estabilizar, espero que ? seja usado ainda mais.

@ ben0x539 Acho que devemos reservar ... para genéricos variados, assim que estivermos prontos para recebê- los

Eu realmente gosto da ideia de inovar com a sintaxe postfix aqui. Faz muito mais sentido com o fluxo e me lembro de como o código ficou muito melhor quando passamos do prefixo try! para o pós-fixado ? . Acho que muitas pessoas experimentaram na comunidade Rust quantas melhorias o código fez.

Se não gostamos da ideia de .await , tenho certeza de que alguma criatividade pode ser feita para encontrar um operador Postfix real. Um exemplo poderia ser apenas usar ++ ou @ para esperar.

:( Eu só não quero esperar mais.

Todos se sentem confortáveis ​​com a sintaxe macro, a maioria das pessoas neste tópico que começam com outras opiniões parecem preferir a sintaxe macro.

Claro que será uma “macro mágica”, mas os usuários raramente se preocupam com a aparência da expansão da macro e, para aqueles que se preocupam, é fácil explicar a nuance nos documentos.

A sintaxe regular da macro é como uma torta de maçã, é a segunda opção favorita de todos, mas, como resultado, a opção favorita da família [0]. É importante ressaltar que como com try! sempre podemos mudar isso mais tarde. Mas o mais importante, quanto mais cedo concordarmos, mais cedo poderemos começar a usá-lo e ser produtivos!

[0] (Referenciado no primeiro minuto) https://www.ted.com/talks/kenneth_cukier_big_data_is_better_data/transcript?language=en

match, if, if let, while, while let e for são todos fluxos de controle generalizados
que usam prefixos. Fingir pausa e continuar são o único fluxo de controle
palavras-chave são frustrantemente enganosas.

No sábado, 19 de janeiro de 2019 às 15:37 Yazad Daruvala [email protected]
escrevi:

:( Eu só não quero esperar mais.

Todos estão confortáveis ​​com a sintaxe macro, a maioria das pessoas neste tópico que
começar com outras opiniões parece acabar favorecendo a sintaxe macro.

Claro, será uma "macro mágica", mas os usuários raramente se preocupam com o que a macro
expansão parece e para aqueles que o fazem, é fácil explicar o
nuance nos documentos.

A sintaxe regular da macro é como uma torta de maçã, é a segunda de todos
opção favorita, mas, como resultado, a opção favorita da família [0].
É importante ressaltar que como com try! sempre podemos mudar isso mais tarde. Mas a maioria
importante, quanto mais cedo concordarmos, mais cedo todos podemos começar
realmente usá-lo e ser produtivo!

[0] (referenciado no primeiro minuto)
https://www.ted.com/talks/kenneth_cukier_big_data_is_better_data/transcript?language=en

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/rust-lang/rust/issues/57640#issuecomment-455824275 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ABGmesz5_LfDKdcKn6zMO5uuSJs9lFiYks5vE6wygaJpZM4aBlba
.

@mitsuhiko eu concordo! Postfix parece mais rústico devido ao encadeamento. Acho que a sintaxe fut@await que propus é outra opção interessante que não parece ter tantas desvantagens quanto outras propostas. Não tenho certeza se é muito longe e uma versão mais realista seria preferível.

@ejmahler

match, if, if let, while, while let e for são todos fluxos de controle generalizados que usam prefixos. Fingir quebras e continuar são as únicas palavras-chave do fluxo de controle é frustrantemente enganoso.

Não é enganoso de forma alguma. A gramática relevante para essas construções é aproximadamente:

Expr = kind:ExprKind;
ExprKind =
  | If:{ "if" cond:Cond then:Block { "else" else_expr:ElseExpr }? };
  | Match:{ "match" expr:Expr "{" arms:MatchArm* "}" }
  | While:{ { label:LIFETIME ":" }? "while" cond:Cond body:Block }
  | For:{ { label:LIFETIME ":" }? "for" pat:Pat "in" expr:Expr body:Block }
  ;

Cond =
  | Bool:Expr
  | Let:{ "let" pat:Pat "=" expr:Expr }
  ;

ElseExpr =
  | Block:Block
  | If:If
  ;

MatchArm = pats:Pat+ % "|" { "if" guard:Expr }? "=>" body:Expr ","?;

Aqui, os formulários são if/while expr block , for pat in expr block e match expr { pat0 => expr0, .., patn => exprn } . Existe uma palavra-chave que precede o que se segue em todas essas formas. Eu acho que é isso que você quer dizer com "usa prefixos". No entanto, todas essas são formas de bloco e não operadores de prefixo unário. A comparação com await expr é, portanto, enganosa, pois não há consistência ou regra para falar. Se você está buscando consistência com formas de bloco, então compare isso com await block , não await expr .

@mitsuhiko eu concordo! Postfix parece mais rústico devido ao encadeamento.

A ferrugem é dualista. Suporta abordagens imperativas e funcionais. E eu acho que está tudo bem, porque em casos diferentes, cada um deles pode ser mais adequado.

Eu não sei. Parece que seria ótimo ter os dois:

await foo.bar();
foo.bar().await;

Tendo usado o Scala por um tempo, eu também gostava muito de muitas coisas que funcionavam assim. Especialmente match e if seria um bom ter em posições postfix em Rust.

foo.bar().await.match {
   Bar1(x, y) => {x==y},
   Bar2(y) => {y==7},
}.if {
   bazinga();
}

Resumo até agora

Matrizes de opções:

• sem barcos
• mehcode
• HeroicKatora
• AaronFriel
• EyeOfPython

Matriz de resumo de opções (usando @ como sigilo, mas pode ser principalmente qualquer coisa):

| Nome Future<T> | Future<Result<T, E>> | Result<Future<T>, E> |
| --- | --- | --- | --- |
| PREFIX | - | - | - |
| Macro de palavras-chave | await!(fut) | await!(fut)? | await!(fut?) |
| Função de palavra-chave | await(fut) | await(fut)? | await(fut?) |
| Precedência útil | await fut | await fut? | await (fut?) |
| Precedência óbvia | await fut | await? fut | await fut? |
| POSTFIX | - | - | - |
| Fn com palavra-chave | fut(await) | fut(await)? | fut?(await) |
| Palavra-chave Campo | fut.await | fut.await? | fut?.await |
| Método de palavra-chave | fut.await() | fut.await()? | fut?.await() |
| Macro de palavras-chave do Postfix | fut.await!() | fut.await!()? | fut?.await!() |
| Palavra-chave do espaço | fut await | fut await? | fut? await |
| Sigil Palavra-chave | fut@await | fut@await? | fut?@await |
| Sigil | fut@ | fut@? | fut?@ |

O sigilo de "Sigil Keyword" _não pode ser # , pois então você não poderia fazê-lo com um futuro chamado r . ... porque o sigilo não teria que mudar a tokenização como minha primeira preocupação .

Mais uso da vida real (envie-me por PM outros casos de uso _real_ com vários await no urlo e irei adicioná-los):

| Nome (reqwest) Client |> Client::get |> RequestBuilder::send |> await |> ? |> Response::json | > ? |
| --- | --- |
| PREFIX | - |
| Macro de palavras-chave | await!(client.get("url").send())?.json()? |
| Função de palavra-chave | await(client.get("url").send())?.json()? |
| Precedência útil | (await client.get("url").send()?).json()? |
| Precedência óbvia | (await? client.get("url").send()).json()? |
| POSTFIX | - |
| Fn com palavra-chave | client.get("url").send()(await)?.json()? |
| Palavra-chave Campo | client.get("url").send().await?.json()? |
| Método de palavra-chave | client.get("url").send().await()?.json()? |
| Macro de palavras-chave do Postfix | client.get("url").send().await!()?.json()? |
| Palavra-chave do espaço | client.get("url").send() await?.json()? |
| Sigil Palavra-chave | client.get("url").send()@await?.json()? |
| Sigil | client.get("url").send()@?.json()? |

NOTA DE EDIÇÃO: foi apontado para mim que pode fazer sentido para Response::json retornar também Future , onde send aguarda o pedido de veiculação de saída e json (ou outra interpretação do resultado) aguarda o IO de entrada. No entanto, vou deixar este exemplo como está, pois acho significativo mostrar que o problema de encadeamento se aplica mesmo com apenas um ponto de espera de E / S na expressão.

Parece haver um consenso aproximado de que, das opções de prefixo, a precedência óbvia (junto com o açúcar await? ) é a mais desejável. No entanto, muitas pessoas se manifestaram a favor de uma solução postfix, a fim de tornar o encadeamento como acima mais fácil. Embora a escolha do prefixo tenha um consenso aproximado, parece não haver consenso sobre qual solução pós-fixada é a melhor. Todas as opções propostas levam a uma confusão fácil (atenuada pelo destaque de palavras-chave):

• Fn com palavra-chave => chamando um fn com um argumento chamado await
• Campo de palavra-chave => acesso de campo
• Método de palavra-chave => chamada de método
• Macro (prefixo ou postfix) => await uma palavra-chave ou não?
• Palavra-chave de espaço => quebra o agrupamento em uma linha (melhor em várias linhas?)
• Sigil => adiciona novos sigilos a uma linguagem que já é percebida como cheia de sigilos

Outras sugestões mais drásticas:

• Permita ambos prefixo (precedência óbvia) e pós-fixo "campo" (isso poderia ser aplicado a mais palavras-chave como match , if , etc. no futuro para tornar este um padrão generalizado, mas é desnecessário adendo a este debate) [[referência] (https://github.com/rust-lang/rust/issues/57640#issuecomment-455827164)]
• await em padrões para resolver futuros (sem encadeamento) [[referência] (https://github.com/rust-lang/rust/issues/57640)]
• Use um operador de prefixo, mas permita atrasá-lo [[referência] (https://github.com/rust-lang/rust/issues/57640#issuecomment-455782394)]

Estabilizar com uma macro de palavra-chave await!(fut) é, obviamente, compatível com o futuro basicamente com todos os itens acima, embora isso exija que a macro use uma palavra-chave em vez de um identificador regular.

Se alguém tiver um exemplo predominantemente real que usa dois await em uma cadeia, eu adoraria vê-lo; ninguém compartilhou um até agora. No entanto, o postfix await também é útil mesmo se você não precisar await mais de uma vez em uma cadeia, como mostrado no exemplo reqwest.

Se perdi algo notável acima deste comentário resumido, envie-me por PM no urlo e tentarei adicioná-lo. (Embora exija que seja adicionado os comentários de outra pessoa para evitar favoritismo de voz alta.)

Pessoalmente, sempre fui a favor de palavras-chave de prefixo com precedência óbvia. Ainda acho que estabilizar com uma macro de palavra-chave await!(fut) seria útil para coletar informações do mundo real sobre onde a espera acontece em casos de uso do mundo real e ainda nos permitiria adicionar um prefixo não macro ou opção de pós-correção posteriormente .

No entanto, no processo de redação do resumo acima, comecei a gostar de "Campo de palavra-chave". A "palavra-chave do espaço" é agradável quando dividida em várias linhas:

client
    .get("url")
    .send() await?
    .json()?

mas em uma linha, faz uma quebra estranha que agrupa mal a expressão: client.get("url").send() await?.json()? . No entanto, com o campo de palavra-chave, parece bom nas duas formas: client.get("url").send().await?.json()?

client
    .get("url")
    .send()
    .await?
    .json()?

embora eu suponha que um "método de palavra-chave" fluiria melhor, pois é uma ação. Nós _poderíamos_ até torná-lo um método "real" em Future se quiséssemos:

trait Future<..> {
    ..
    extern "rust-await" fn r#await(self) -> _;
}

( extern "rust-await" certamente implicaria em toda a magia necessária para realmente fazer o await e não seria realmente um fn real, apenas estaria lá porque a sintaxe se parece com um método, se uma palavra-chave método é usado.)

Permitir prefixo (precedência óbvia) e pós-fixo "campo" ...

Se qualquer sintaxe pós-fixada for selecionada (não importa se junto ou em vez do prefixo), definitivamente seria um argumento para uma discussão futura: agora temos palavras-chave que funcionam tanto em notação prefixada quanto pós-fixada, precisamente porque às vezes uma é preferível a o outro, então talvez pudéssemos permitir ambos onde faz sentido e aumentar a flexibilidade da sintaxe, enquanto unificamos as regras. Talvez seja uma má ideia, talvez seja rejeitada, mas é definitivamente uma discussão a ser feita no futuro, se a notação Postix for usada para await .

Acho que há muito pouca chance de uma sintaxe que não inclua a string de caracteres await ser aceita para esta sintaxe.

: +1:

Um pensamento aleatório que tive depois de ver um monte de exemplos aqui ( como @mehcode 's ): Uma das reclamações de que me lembro sobre .await é que é muito difícil de ver †, mas considerando que as coisas esperadas são normalmente falível, o fato de que geralmente é .await? ajuda a chamar atenção extra para ele de qualquer maneira.

† Se você estiver usando algo que não destaca palavras-chave

@ejmahler

Eu me oponho a qualquer sintaxe que não seja parecida com o inglês

Algo como request.get().await lido tão bem quanto body.lines().collect() . Em "um monte de métodos iteradores encadeados", acho que _prefixo_ na verdade é pior, já que você tem que lembrar que eles disseram "espere" bem no início, e nunca saberá quando ouvir algo se será o que você esperando, meio que como uma frase no caminho do jardim .

E depois de anos usando-os no código de produção, minha convicção é que saber onde estão seus pontos de rendimento, à primeira vista, é absolutamente crítico. Quando você desliza para baixo a linha de indentação da sua função, você pode escolher cada retorno de co_await / yield em uma função de 200 linhas em questão de segundos, sem carga cognitiva.

Isso implica que nunca há nenhum dentro de uma expressão, o que é uma restrição que eu absolutamente não apoiaria, dada a natureza orientada por expressão de Rust. E pelo menos com await , é absolutamente plausível ter CallSomething(argument, await whatever.Foo() .

Dado que async _will_ aparecem no meio das expressões, não entendo por que é mais fácil ver no prefixo do que no pós-fixado.

Deve receber o mesmo nível de respeito de 'se, enquanto, corresponder e retornar. Imagine se qualquer um desses fossem operadores postfix - ler o código do Rust seria um pesadelo.

return (e continue e break ) e while são notáveis ​​como _completamente_ inúteis para encadear, já que sempre retornam ! e () . E embora por algum motivo você tenha omitido for , vimos código escrito muito bem usando .for_each() sem efeitos negativos, particularmente em rayon .

Provavelmente precisamos aceitar o fato de que async/await será um recurso importante da linguagem. Ele aparecerá em todos os tipos de código. Ele vai invadir o ecossistema - em alguns lugares, será tão comum quanto ? . As pessoas terão que aprender.

Conseqüentemente, podemos querer focalizar conscientemente em como a escolha da sintaxe parecerá depois de usá-la por um longo tempo, em vez de como será a princípio.

Também precisamos entender que, no que diz respeito às construções de fluxo de controle, await é um tipo diferente de animal. Construções como return , break , continue e até yield podem ser entendidas intuitivamente em termos de jmp . Quando os vemos, nossos olhos saltam pela tela porque o fluxo de controle com o qual nos importamos está se movendo para outro lugar. No entanto, embora await afete o fluxo de controle da máquina, ele não move o fluxo de controle que é importante para nossos olhos e para nossa compreensão intuitiva do código.

Não somos tentados a encadear chamadas incondicionais para return ou break porque isso não faria sentido. Por motivos semelhantes, não somos tentados a alterar nossas regras de precedência para acomodá-las. Esses operadores têm baixa precedência. Eles levam tudo à direita e o devolvem em algum lugar, encerrando a execução dentro daquela função ou bloco. O operador await , entretanto, deseja ser encadeado. É parte integrante de uma expressão, não o fim dela.

Tendo considerado a discussão e os exemplos neste tópico, fico com a sensação corrosiva de que viveríamos para nos arrepender das surpreendentes regras de precedência.

O candidato a stalking horse parece estar indo com await!(expr) por enquanto e esperando que algo melhor seja resolvido mais tarde. Antes de ler os comentários de @Centril , eu provavelmente teria apoiado isso no interesse de obter esse recurso importante com quase qualquer sintaxe. No entanto, seus argumentos me convencem de que isso seria apenas uma fuga. Sabemos que o encadeamento de chamadas de método é importante no Rust. Isso levou à adoção da palavra-chave ? , que é amplamente popular e extremamente bem-sucedida. Usar uma sintaxe que sabemos que nos desapontará é, na verdade, apenas adicionar uma dívida técnica.

No início deste tópico, @withoutboats indicou que apenas quatro opções existentes parecem viáveis. Destes, apenas a sintaxe pós-fixada expr await provavelmente nos fará felizes a longo prazo. Essa sintaxe não cria surpresas estranhas de precedência. Isso não nos força a criar uma versão de prefixo do operador ? . Ele funciona bem com encadeamento de métodos e não interrompe o fluxo de controle da esquerda para a direita. Nosso operador ? sucesso serve como precedente para um operador postfix, e await é mais parecido com ? na prática do que com return , break ou yield . Embora um operador postfix sem símbolo possa ser novo no Rust, o uso de async/await será amplamente difundido para torná-lo rapidamente familiar.

Embora todas as opções para uma sintaxe postfix pareçam viáveis, expr await tem algumas vantagens. Essa sintaxe deixa claro que await é uma palavra-chave, o que ajuda a enfatizar o fluxo de controle mágico. Comparado com expr.await , expr.await() expr.await! , expr.await!() , etc., isso evita ter que explicar que se parece com um campo / método / macro, mas realmente não está neste caso especial. Todos nós nos acostumaríamos com o separador de espaço aqui.

Soletrar await como @ ou usar algum outro símbolo que não cause problemas de análise é atraente. Certamente é um operador importante o suficiente para justificá-lo. Mas se, no final, tiver que ser escrito await , tudo bem. Contanto que esteja na posição postfix.

Como alguém mencionou exemplos _real_ ... Eu mantenho uma (de acordo com tokei) 23.858 base de código de ferrugem de linha que é altamente assíncrona e usa futuros 0.1 await (altamente experimental, eu sei). Vamos explorar (redigido) espeleologia (observe que tudo foi executado no rustfmt):

// A
if !await!(db.is_trusted_identity(recipient.clone(), message.key.clone()))? {
    info!("recipient: {}", recipient);
}

// B
match await!(db.load(message.key))? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = await!(client
    .get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .send())?
.error_for_status()?;

// D
let mut res =
    await!(client.get(inbox_url).headers(inbox_headers).send())?.error_for_status()?;

let mut res: InboxResponse = await!(res.json())?;

// E
let mut res = await!(client
    .post(url)
    .multipart(form)
    .headers(headers.clone())
    .send())?
.error_for_status()?;

let res: Response = await!(res.json())?;

// F
#[async]
fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let (_, mut res) = await!(self.request(url, Method::GET, None, true))?;
    let user = await!(res.json::<UserResponse>())?
        .user
        .into();

    Ok(user)
}

Agora vamos transformar isso na variante de prefixo mais popular, precedência óbvia com açúcar. Por razões óbvias, isso não foi executado em rustfmt, então, desculpe se houver uma maneira melhor de escrevê-lo.

// A
if await? db.is_trusted_identity(recipient.clone(), message.key.clone()) {
    info!("recipient: {}", recipient);
}

// B
match await? db.load(message.key) {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = (await? client
    .get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .send())
.error_for_status()?;

// D
let mut res =
    (await? client.get(inbox_url).headers(inbox_headers).send()).error_for_status()?;

let mut res: InboxResponse = await? res.json();

// E
let mut res = (await? client
    .post(url)
    .multipart(form)
    .headers(headers.clone())
    .send())
.error_for_status()?;

let res: Response = await? res.json();

// F
async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let (_, mut res) = await? self.request(url, Method::GET, None, true);
    let user = (await? res.json::<UserResponse>())
        .user
        .into();

    Ok(user)
}

Finalmente, vamos transformar isso em minha variante postfix favorita, "campo postfix".

// A
if db.is_trusted_identity(recipient.clone(), message.key.clone()).await? {
    info!("recipient: {}", recipient);
}

// B
match db.load(message.key).await? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .send().await?
    .error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .send().await?
    .error_for_status()?
    .json().await?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .send().await?
    .error_for_status()?
    .json().await?;

// F
async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.request(url, Method::GET, None, true).await?
        .res.json::<UserResponse>().await?
        .user
        .into();

    Ok(user)
}

Após este exercício, descobri várias coisas.

• Agora sou fortemente contra await? foo . Ele tem uma boa leitura para expressões simples, mas ? parece perdido em expressões complexas. Se devemos usar prefixo, prefiro ter precedência "útil".

• O uso de notação pós-fixada me leva a juntar instruções e reduzir ligações let desnecessárias.

• Usar a notação postfix _field_ me leva a fortemente preferir .await? para aparecer na linha da coisa que está esperando ao invés de em sua própria linha na linguagem rustfmt.

Agradeço a notação pós-fixada de reticências "..." acima, tanto por sua concisão quanto simbolicamente na língua inglesa, representando uma pausa em antecipação a outra coisa. (Assim como funciona o comportamento assíncrono!), Ele também se encadeia bem.

let resultValue = doSomethingAndReturnResult()...?;
let resultValue = doSomethingAndReturnResult()...?.doSomethingOnResult()...?;
let value = doSomethingAndReturnValue()....doSomethingOnValue()...;
let arrayOfValues = vec![doSomethingA(),doSomethingB()]...?;
// Showing stacking
let value = doSomethingWithVeryLongFunctionName()...?
                 .doSomethingWithResult()...?;

Duvido que qualquer outra opção seja tão concisa e visualmente significativa.

UMA

let mut res: Response = (await client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .send().await?
    .error_for_status()?
    .json())?;

B

let mut res: Response = await client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .send().await?
    .error_for_status()?
    .json());
let res = res.unwrap();

Deve mesmo ser considerado uma boa forma ter longas cadeias de espera?

Por que não usar simplesmente combinadores Future regulares?

Na verdade, algumas expressões não se traduzem bem em cadeias de espera se você quiser ter comportamentos de backup em caso de falha.

Pessoalmente, penso o seguinte:

let value = await some_op()
                 .and_then(|v| v.another_op())
                 .and_then(|v2| v2.final_op())
                 .or_else(|| backup_op());

value.unwrap()

lê muito mais naturalmente do que isso:

let value = match await some_op() {
    Ok(v) => match await v.another_op() {
        Ok(v2) => await v2.final_op(),
        Err(_) => await backup_op(),
    },
    Err(_) => await backup_op(),
};

value.unwrap()

Afinal, ainda temos todo o poder dos futuros a custo zero em nossas mãos.

Considere isso.

@EyeOfPython Eu gostaria de @ em future@await . Podemos escrever future~await , onde ~ funciona como um semi-hífen, e funcionaria para qualquer operador posfixo possível.

O hífen - já foi usado como o operador menos e operador negativo. Não é mais bom. Mas ~ foi usado para indicar objetos heap no Rust e, de outra forma, dificilmente foi usado em qualquer linguagem de programação. Deve causar menos confusão para pessoas de outras línguas.

@earthengine Boa ideia, mas talvez use apenas future~ que significa aguardar um futuro, onde ~ é trabalhado como a palavra-chave await . (como o símbolo ?

Futuro | Futuro do Resultado | Resultado do Futuro
- | - | -
futuro ~ | futuro ~? | futuro? ~

Também futuros acorrentados como:

let res: MyResponse = client.get("https://my_api").send()~?.json()~?;

Dei uma olhada em como Go implementa a programação assíncrona e descobri algo interessante lá. A alternativa mais próxima aos futuros em Go são os canais. E em vez de await ou outra sintaxe gritante para esperar por valores, os canais Go fornecem apenas o operador <- para esse propósito. Para mim, parece muito claro e direto. Já vi muitas vezes como as pessoas elogiam Go por sua sintaxe simples e bons recursos assíncronos, então é definitivamente uma boa ideia aprender algo com sua experiência.

Infelizmente, não poderíamos ter exatamente a mesma sintaxe porque há muito mais colchetes angulares no código-fonte do Rust do que no Go, principalmente por causa dos genéricos. Isso torna o operador <- realmente sutil e desagradável de se trabalhar. Outra desvantagem é que ele pode ser visto como oposto a -> na assinatura de função e não há razão para considerá-lo assim. E ainda outra desvantagem é que <- sigilo foi planejado para ser implementado como placement new , então as pessoas poderiam interpretá-lo mal.

Então, depois de alguns experimentos com a sintaxe, parei em <-- sigil:

let output = <-- future;

No contexto async <-- é bastante simples, embora seja inferior a <- . Mas, em vez disso, fornece uma grande vantagem sobre <- , bem como sobre o prefixo await - funciona bem com indentação.

async fn log_service(&self) -> T {
   let service = self.myService.foo();
   <-- self.logger.log("beginning service call");
   let output = <-- service.exec();
   <-- self.logger.log("foo executed with result {}.", output));
   output
}

async fn try_log(message: String) -> Result<usize, Error> {
    let logger = <-- acquire_lock();
    let length = <-- logger.log_into(message)?;
    <-- logger.timestamp();
    Ok(length)
}

async fn await_chain() -> Result<usize, Error> {
    <-- (<-- partial_computation()).unwrap_or_else(or_recover);
}

Para mim, esse operador parece ainda mais exclusivo e fácil de detectar do que await (que se parece mais com qualquer outra palavra-chave ou variável no contexto do código). Infelizmente, no Github parece mais fino do que no meu editor de código, mas acho que não é fatal e podemos viver com isso. Mesmo que alguém se sinta desconfortável, diferentes realces de sintaxe ou fontes melhores (especialmente com ligaduras) resolverão todos os problemas.

Outro motivo para gostar dessa sintaxe é porque ela poderia ser expressa conceitualmente como "algo que ainda não está aqui". A direção da direita para a esquerda da seta é oposta à direção como lemos o texto, o que nos permite descrevê-lo como "coisa que vem do futuro". A forma longa do operador <-- também sugere que "alguma operação durável começa". O colchete angular e dois hifens direcionados a future podem simbolizar "votação contínua". E ainda podemos ler como "aguardar" como era antes.
Não é algum tipo de iluminação, mas pode ser divertido.

O mais importante nesta proposta é que o encadeamento de métodos ergonômicos também seria possível. A ideia de operador de prefixo atrasado que propus anteriormente se encaixa bem aqui. Desta forma, teríamos o melhor de ambos os mundos da sintaxe de prefixo e pós-fixado await . Eu realmente espero que também sejam introduzidos alguns extras úteis que eu pessoalmente desejei em muitas ocasiões antes: desreferenciação retardada e sintaxe de negação retardada .

Completo, não tenho certeza se palavra atrasada é adequada aqui, talvez devêssemos nomeá-la de forma diferente.

client.get("https://my_api").<--send()?.<--json()?

let not_empty = some_vec.!is_empty();

let deref = value.*as_ref();

A precedência do operador parece bastante óbvia: da esquerda para a direita.

Espero que esta sintaxe reduza a necessidade de escrever is_not_* funções cujo objetivo é apenas negar e retornar uma propriedade bool . E expressões booleanas / desreferenciadas em alguns casos serão mais limpas ao usá-las.

Finalmente, apliquei em exemplos do mundo real postados por @mehcode e gosto de como <-- dá ênfase adequada à função async dentro das cadeias de chamada de método. Ao contrário, o postfix await apenas se parece com acesso de campo regular ou chamada de função (dependendo da sintaxe) e é quase impossível distingui-los sem um destaque especial de sintaxe ou formatação.

// A
if db.<--is_trusted_identity(recipient.clone(), message.key.clone())? {
    info!("recipient: {}", recipient);
}

// B
match db.<--load(message.key)? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .<--send()?
    .error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .<--send()?
    .error_for_status()?
    .<--json()?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .<--send()?
    .error_for_status()?
    .<--json()?;

// F
async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.<--request(url, Method::GET, None, true)?
        .res.<--json::<UserResponse>()?
        .user
        .into();

    Ok(user)
}

Afinal: essa é a sintaxe que desejo usar.

@novacrazy

Deve mesmo ser considerado uma boa forma ter longas cadeias de espera? Por que não usar simplesmente combinadores Future regulares?

Não tenho certeza se não entendi você mal, mas esses não são exclusivos, você ainda pode usar combinadores também

let value = some_op()
    .and_then(|v| v.another_op())
    .and_then(|v2| v2.final_op())
    .or_else(|| backup_op())
    .await;

Mas para que isso funcione, a cláusula and_then precisa ser digitada em FnOnce(T) -> impl Future<_> , não apenas em FnOnce(T) -> U . Fazer combinadores encadeados no futuro e o resultado só funcionará perfeitamente sem parênteses no postfix:

let result = load_local_file()
    .or_else(|_| request_from_server()) // Async combinator
    .await
    .and_then(|body| serde_json::from_str(&body)); // Sync combinator

Nesta postagem, vou me concentrar na questão da precedência do

• Chamada de método ( future.await() )
• Expressão de campo ( future.await )
• Chamada de função ( future(await) )

As diferenças de funcionalidade são bastante pequenas, mas existentes. Observe que eu aceitaria tudo isso, isso é principalmente ajuste fino. Para mostrá-los todos, precisamos de alguns tipos. Por favor, não comente sobre as artimanhas do exemplo, esta é a versão mais compactada que mostra todas as diferenças de uma vez.

struct Foo<A, F, S> where A: Future<Output=F>, F: FnOnce(usize) -> S {
    member: A,
}

// What we want to do, in macro syntax:
let foo: Foo<_, _, _> = …;
(await!(foo.member))(42)

• Chamada de método: foo.member.await()(42)
  Vincula-se mais fortemente, então nenhuma parêntese
• Membro: (foo.member.await)(42)
  Precisa de parênteses em torno do resultado esperado quando este é um chamável, isso é consistente com ter um chamável como um membro, caso contrário, confusão com a chamada à função de membro. Isso também sugere que se pode desestruturar com padrões: let … { await: value } = foo.member; value(42) alguma forma?
• Chamada de função: (foo.member)(await)(42)
  Necessita de parênteses para desestruturação (movemos o membro), pois ele se comporta como uma chamada de função.

Todos eles parecem iguais quando não desestruturamos uma estrutura de entrada por meio da movimentação de um membro, nem chamamos o resultado como um chamável, pois essas três classes de precedência vêm diretamente uma após a outra. Como queremos que os futuros se comportem?

O melhor paralelo para a chamada de método deve ser apenas outra chamada de método usando self .

O melhor paralelo para o membro é uma estrutura que tem apenas o membro implícito await e, portanto, é desestruturada ao se mover a partir dele, e essa movimentação implicitamente espera o futuro. Este parece o menos óbvio.

O paralelo à função é chamada é o comportamento dos fechamentos. Eu preferiria esta solução como a adição mais limpa ao corpus da linguagem (como na sintaxe melhor paralela as possibilidades do tipo), mas são alguns pontos positivos para a chamada de método e .await nunca é maior que os outros.

@HeroicKatora Poderíamos .await em libsyntax para permitir foo.await(42) mas isso seria inconsistente / ad-hoc. No entanto, (foo.await)(42) parece útil, pois embora existam encerramentos de saída de futuros, eles provavelmente não são tão comuns. Portanto, se otimizarmos para o caso comum, não ter que adicionar () a .await provavelmente sairá vencedor.

@Centril Concordo, a consistência é importante. Quando vejo alguns comportamentos semelhantes, gostaria de inferir outros por meio de síntese. Mas aqui .await parece estranho, especialmente com o exemplo acima mostrando claramente que ele é paralelo à desestruturação implícita (a menos que você possa encontrar uma sintaxe diferente onde esses efeitos ocorrem?). Quando vejo a desestruturação, imediatamente me pergunto se posso usar isso com let-bindings etc. Isso, no entanto, não seria possível porque destruiríamos o tipo original que não tem tal membro ou especialmente quando o tipo é apenas impl Future<Output=F> (Nota notória irrelevante: fazer isso funcionar nos levaria de volta a um prefixo alternativo await _ = no lugar de let _ = , engraçado¹).

Isso não nos proíbe de usar a sintaxe em si, acho que poderia lidar com o aprendizado e se for a última vou usá-la com vigor, mas parece uma clara fraqueza.

¹ Isso pode ser consistente ao permitir ? ao permitir ? atrás de nomes em um padrão

• await value? = failing_future();

para corresponder à parte Ok de Result . Parece interessante explorar também em outros contextos, mas fora do tópico. Isso também levaria à correspondência de sintaxe de prefixo e sufixo para await ao mesmo tempo.

Isso não nos proíbe de usar a sintaxe em si, acho que poderia lidar com o aprendizado e se for a última vou usá-la com vigor, mas parece uma clara fraqueza.

Acho que toda solução terá alguma desvantagem em alguma dimensão ou caso. consistência, ergonomia, capacidade de encadeamento, legibilidade, ... Isso torna uma questão de grau, importância dos casos, adequação ao código Rust típico e APIs, etc.

No caso de um usuário escrevendo foo.await(42) ...

struct HasClosure<F: FnOnce(u8)> { closure: F, }
fn _foo() {
    let foo: HasClosure<_> = HasClosure { closure: |x| {} };

    foo.closure(42);
}

... já fornecemos bons diagnósticos:

5 |     foo.closure(42);
  |         ^^^^^^^ field, not a method
  |
  = help: use `(foo.closure)(...)` if you meant to call the function stored in the
          `closure` field

Ajustar isso para caber em foo.await(42) parece bastante atingível. Na verdade, pelo que posso ver, sabemos que o usuário pretende (foo.await)(42) quando foo.await(42) está escrito, então isso pode ser cargo fix ed em um MachineApplicable maneira. De fato, se estabilizarmos foo.await mas não permitirmos foo.await(42) , acredito que podemos até mesmo mudar a precedência mais tarde se precisarmos, já que foo.await(42) não será legal no início.

Outros aninhamentos funcionariam (por exemplo, futuro do resultado do fechamento - não que isso seja comum):
`` `ferrugem
struct HasClosure fn _foo () -> Resultado <(), ()> {
deixe foo: HasClosure <_ i = "27"> = HasClosure {encerramento: Ok (| x | {})};

foo.closure?(42);

Ok(())

}

por exemplo, futuro do resultado do fechamento - não que isso seja comum

O sufixo extra ? operador torna isso inequívoco, sem modificações na sintaxe - em qualquer um dos exemplos pós-correção. Não há necessidade de ajustes . Os problemas são apenas .member sendo explicitamente um campo e a necessidade de se aplicar a desestruturação de movimento primeiro. E eu realmente não quero dizer que isso seria difícil de escrever. Eu quero dizer principalmente que isso parece inconsistente com outros .member usos que, por exemplo, podem ser transformados em correspondência. A postagem original pesava pontos positivos e negativos a esse respeito.

Editar: Ajustar para caber future.await(42) tem o risco extra, provavelmente não intencional, de tornar isso a) inconsistente com fechamentos onde este não é o caso devido a métodos com o mesmo nome do membro serem permitidos; b) inibir desenvolvimentos futuros onde gostaríamos de dar argumentos para await . Mas, como você mencionou anteriormente, ajustar Future retornar um fechamento não deve ser a questão mais urgente.

@novacrazy Por que não usar simplesmente combinadores Future regulares?

Não tenho certeza de quanta experiência você tem com Futures 0.3, mas a expectativa geral é que os combinadores não serão muito usados, e o uso primário / idiomático será assíncrono / aguardar.

Async / await tem várias vantagens sobre os combinadores, por exemplo, oferece suporte a empréstimos em pontos de rendimento.

Os combinadores existiam muito antes de async / await, mas async / await foi inventado de qualquer maneira e por um bom motivo!

Async / await veio para ficar, o que significa que precisa ser ergonômico (inclusive com cadeias de métodos).

Claro que as pessoas são livres para usar os combinadores se quiserem, mas eles não deveriam ser necessários para se obter uma boa ergonomia.

Como @cramertj disse, vamos tentar manter a discussão focada em async / await, não alternativas para async / await.

Na verdade, algumas expressões não se traduzem bem em cadeias de espera se você quiser ter comportamentos de backup em caso de falha.

Seu exemplo pode ser simplificado significativamente:

let value = try {
    let v = await some_op()?;
    let v2 = await v.another_op()?;
    await v2.final_op()?
};

match value {
    Ok(value) => Ok(value),
    Err(_) => await backup_op(),
}.unwrap()

Isso deixa claro quais partes estão lidando com o erro e quais partes estão no caminho normal de felicidade.

Esta é uma das melhores coisas sobre async / await: funciona bem com outras partes da linguagem, incluindo loops, branches, match , ? , try , etc.

Na verdade, além de await , este é o mesmo código que você escreveria se não estivesse usando Futuros.

Outra maneira de escrever, se você preferir usar o combinador or_else :

let value = await async {
    try {
        let v = await some_op()?;
        let v2 = await v.another_op()?;
        await v2.final_op()?
    }
}.or_else(|_| backup_op());

value.unwrap()

E o melhor de tudo é mover o código normal para uma função separada, tornando o código de tratamento de erros ainda mais claro:

async fn doit() -> Result<Foo, Bar> {
    let v = await some_op()?;
    let v2 = await v.another_op()?;
    await v2.final_op()
}

let value = await doit().or_else(|_| backup_op());

value.unwrap()

(Esta é uma resposta ao comentário de @joshtriplett ).

Para ser claro, você não precisa colocar parênteses, eu mencionei isso porque algumas pessoas disseram que é muito difícil ler sem os parênteses. Portanto, os parênteses são uma escolha estilística opcional (útil apenas para frases complexas).

Todas as sintaxes se beneficiam de parênteses em algumas situações, nenhuma das sintaxes é perfeita, é uma questão de quais situações queremos otimizar.

Além disso, depois de reler seu comentário, talvez você tenha pensado que eu estava defendendo o prefixo await ? Eu não estava, meu exemplo estava usando o postfix await . No geral, gosto do postfix await , embora também goste de algumas das outras sintaxes.

Estou começando a ficar confortável com fut.await , acho que a reação inicial das pessoas será "Espere, é assim que você espera? Estranho." mas, mais tarde, eles adorariam pela conveniência. Claro, o mesmo é verdadeiro para @await , que se destaca muito mais do que .await .

Com essa sintaxe, podemos deixar de fora algumas das deixa no exemplo:

let value = try {
    some_op().await?
        .another_op().await?
        .final_op().await?
};

match value {
    Ok(value) => Ok(value),
    Err(_) => backup_op().await,
}.unwrap()

let value = try {
    some_op()@await?
        .another_op()@await?
        .final_op()@await?
};

match value {
    Ok(value) => Ok(value),
    Err(_) => backup_op()<strong i="21">@await</strong>,
}.unwrap()

Isso também torna mais claro o que está sendo desembrulhado com ? , para await some_op()? , não é óbvio se some_op() foi desembrulhado ou o resultado esperado.

@Pauan

Não estou tentando desviar o foco do tópico aqui, estou tentando apontar que ele não existe em uma bolha. Temos que considerar como as coisas funcionam juntas .

Mesmo que a sintaxe ideal fosse escolhida, eu ainda gostaria de usar futuros personalizados e combinadores em algumas situações. A ideia de que aqueles poderiam ser descontinuados me faz questionar toda a direção de Rust.

Os exemplos que você deu ainda parecem terríveis em comparação com os combinadores e, com a sobrecarga do gerador, provavelmente serão um pouco mais lentos e produzirão mais código de máquina.

Até onde vai, todo esse prefixo / sigilo pós-fixo / palavra-chave recriação de bicicletas é maravilhoso, mas talvez devêssemos ser pragmáticos e ir com a opção mais simples que é mais familiar para os usuários que vêm para o Rust. Ou seja: prefixo palavra-chave

Este ano vai passar mais rápido do que pensamos. Até janeiro está quase tudo pronto. Se descobrir que os usuários não estão satisfeitos com uma palavra-chave de prefixo, ela pode ser alterada em uma edição 2019/2020. Podemos até fazer uma piada do tipo “retrospectiva é 2020”.

@novacrazy

O consenso geral que vi é que o _primeiro_ que gostaríamos de uma terceira edição é 2022. Definitivamente, não queremos planejar outra edição; a edição de 2018 foi ótima, mas teve seus custos. (E um dos pontos da edição 2018 é tornar assíncrono / esperar possível, imagine pegar isso de volta e dizer "não, você precisa atualizar para a edição 2020 agora!")

Em qualquer caso, não acho que uma palavra-chave de prefixo -> transição de palavra-chave postfix seja possível em uma edição, mesmo que isso fosse desejável. A regra em torno das edições é que deve haver uma maneira de escrever código idiomático na edição X de forma que compile sem avisos e funcione da mesma forma na edição X + 1.

É o mesmo motivo pelo qual preferimos não nos estabilizar com uma macro de palavras-chave se pudermos gerar um consenso sobre uma solução diferente; estabilizar deliberadamente uma solução que sabemos ser indesejável é em si problemático.

Acho que mostramos que uma solução postfix é mais ideal, mesmo para expressões com apenas um ponto de espera. Mas eu duvido que qualquer uma das soluções postfix propostas seja obviamente melhor do que todas as outras.

Apenas meus dois centavos (não sou ninguém, mas acompanho a discussão há muito tempo). Minha solução favorita seria a versão postfix @await . Talvez você pudesse considerar um postfix !await , como alguma nova sintaxe de macro postfix?

Exemplo:

let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .send()!await?
    .error_for_status()?
    .json()!await?;

Depois de algumas iterações de linguagem, ser capaz de implementar nossas próprias macros postfix seria incrível.

... todas as novas propostas sygils

Rust já tem sintaxe / sygil pesada, temos await palavra-chave reservada, stuff@await (ou qualquer outro sygil) parece estranho / feio (subjetivo, eu sei), e é apenas uma sintaxe ad-hoc que não se integra com mais nada na língua, o que é uma grande bandeira vermelha.

Eu dei uma olhada em como Go implementa
... <- ... proposta

@ I60R : Go tem uma sintaxe terrível cheia de soluções ad-hoc e é totalmente imperativo, muito diferente do Rust. Esta proposta é novamente sygil / sintaxe pesada e totalmente ad-hoc apenas para este recurso específico.

@ I60R : Go tem uma sintaxe terrível

Vamos, por favor, evitar criticar outras línguas aqui. "X tem uma sintaxe terrível" não leva à iluminação e ao consenso.

Como um usuário Python / JavaScript / Rust e um estudante de ciência da computação, eu pessoalmente prefiro o prefixo await + f.await() para estar na linguagem.

1. Tanto o Python quanto o JavaScript têm o prefixo await . Eu esperaria ver await aparecer no início. Se eu tiver que ler profundamente na linha para perceber que este é um código assíncrono, me sinto muito desconfortável. Com o recurso WASM do Rust, ele pode atrair muitos desenvolvedores JS. Acredito que familiaridade e conforto são muito importantes, considerando que Rust já tem muitos outros novos conceitos.

2. Postfix await parece conveniente em configurações de encadeamento. No entanto, não gosto de soluções como .await , @await , f await porque se parecem com uma solução ad-hoc para a sintaxe await embora faça sentido pensar .await() como chamando um método no future .

Rust já é uma partida do javascript e await não é nada como chamar função (ou seja, a funcionalidade não pode ser emulada por meio de uma função), usando funções para denotar await torna confuso para os iniciantes que estão sendo introduzidos no async-await. Portanto, acho que a sintaxe deve ser diferente.

Eu me convenci de que .await() é provavelmente significativamente mais desejável do que .await , embora o restante deste post evite um pouco essa posição.

A razão para isso é que await!(fut) tem que _consumir fut por valor_. Fazer com que pareça que o acesso a um campo é _bad_, porque isso não tem a conotação de se mover da maneira que uma palavra-chave de prefixo, ou o potencial de se mover como uma macro ou uma chamada de método.

Curiosamente, a sintaxe do método de palavra-chave quase faz com que pareça um projeto de await implícito . Infelizmente, "Explicit Async, Implicit Await" não é possível para Rust (então _por favor, não litigue-o neste tópico), pois queremos que async fn() -> T seja usado de forma idêntica a fn() -> Future<T> , em vez de ativar um comportamento de "espera implícita".

O fato de que uma sintaxe .await() _parece_ como um sistema de espera implícito (como o Kotlin usa) poderia ser um detrator e quase daria a sensação de uma "Async implícita, espera implícita" devido à magia em torno do não sintaxe de chamada de método .await() . Você poderia usar isso como await(fut) com UFCS? Seria Future::await(fut) para o UFCS? Qualquer sintaxe que se pareça com outra dimensão da linguagem levanta problemas, a menos que possa ser um tanto unificada com ela, pelo menos sintaticamente, mesmo se não funcionalmente.

Continuo cético se os benefícios de qualquer solução postfix _individual_ superam as desvantagens dessa mesma solução, embora o conceito de uma solução postfix seja mais desejável do que um prefixo em geral.

Estou um pouco surpreso que este tópico esteja cheio de sugestões que parecem ser feitas porque são possíveis - e não porque parecem produzir quaisquer benefícios significativos em relação às sugestões iniciais.
Podemos parar de falar sobre $ , # , @ , ! , ~ etc, sem apresentar um argumento significativo sobre o que está errado com await , que é bem compreendida e se provou em várias outras linguagens de programação?

Acho que o post de https://github.com/rust-lang/rust/issues/57640#issuecomment -455361619 já listou todas as boas opções.

Daqueles:

• Delimitadores obrigatórios delimitadores parecem estar bem, pelo menos é óbvio qual é a precedência e podemos ler o código de outros sem mais clareza. E digitar dois parênteses não é tão ruim. Talvez a única desvantagem seja que parece uma chamada de função, embora seja uma operação de fluxo de controle diferente.
• A precedência útil pode ser a opção preferível. Esse parece ser o caminho que a maioria das outras línguas percorreram, por isso é familiar e comprovado.
• Pessoalmente, acho que a palavra-chave postfix com espaço em branco parece estranha com vários awaits em uma única instrução:
  client.get("url").send() await?.json()? . Esse espaço em branco parece fora do lugar. Com parênteses, faria um pouco mais de sentido para mim: (client.get("url").send() await)?.json()?
  Mas acho o fluxo de controle ainda mais difícil de seguir do que com a variante de prefixo.
• Eu não gosto de campo Postfix. await faz uma operação muito complexa - Rust não tem propriedades computáveis ​​e o acesso ao campo é uma operação muito simples. Portanto, parece dar uma impressão errada sobre a complexidade desta operação.
• O método Postfix pode estar OK. Pode encorajar algumas pessoas a escrever declarações muito longas com múltiplas esperas nelas, o que pode ocultar ainda mais os pontos de rendimento. Também faz com que as coisas pareçam uma chamada de método, embora seja algo diferente.

Por essas razões, prefiro a "precedência útil" seguida de "delimitadores obrigatórios"

Go tem uma sintaxe terrível cheia de soluções ad-hoc e é totalmente imperativo, muito diferente do Rust. Esta proposta é novamente sygil / sintaxe pesada e totalmente ad-hoc apenas para este recurso específico.

@dpc , se você ler <-- proposta completamente, verá que essa sintaxe é inspirada apenas em Go, no entanto, é muito diferente e pode ser usada tanto no contexto de encadeamento de funções quanto no imperativo. Também não consigo ver como a sintaxe de await não é uma solução ad-hoc, para mim é muito mais específica e mais desajeitada do que <-- . É semelhante a deref reference / reference.deref / etc em vez de *reference , ou try result / result.try / etc em vez de result? . Eu também não vejo nenhuma vantagem em usar a palavra-chave await além da familiaridade com JS / Python / etc, que de qualquer forma deve ser menos significativa do que ter uma sintaxe consistente e combinável. E eu não vejo nenhuma desvantagem em ter <-- sigilo além de não ser um await que de qualquer forma não é tão simples como o inglês puro e os usuários devem entender o que ele faz primeiro.

Edit: esta também pode ser uma boa resposta para a postagem de @ Matthias247 , uma vez que fornece alguns argumentos contra await e propõe uma possível alternativa não afetada pelos mesmos problemas

É realmente interessante para mim, através, ler críticas contra a sintaxe <-- , livre de argumentos que apelam a razões históricas e preconceituosas.

Vamos mencionar detalhes reais sobre a precedência:

O gráfico de precedência como está hoje :

Operador / Expressão | Associatividade
- | -
Caminhos |
Chamadas de método |
Expressões de campo | da esquerda para direita
Chamadas de função, indexação de matriz |
? |
Unário - * ! & &mut |
as | da esquerda para direita
* / % | da esquerda para direita
+ - | da esquerda para direita
<< >> | da esquerda para direita
& | da esquerda para direita
^ | da esquerda para direita
\| | da esquerda para direita
== != < > <= >= | Requer parênteses
&& | da esquerda para direita
\|\| | da esquerda para direita
.. ..= | Requer parênteses
= += -= *= /= %= &= \|= ^= <<= >>= | direita para esquerda
return break encerramentos |

A precedência útil coloca await antes de ? para que se ligue mais firmemente do que ? . Um ? na cadeia, portanto, vincula um `await a tudo o que está antes dele.

let res = await client
    .get("url")
    .send()?
    .json();

Sim, com precedência útil, isso "simplesmente funciona". Você sabe o que isso faz à primeira vista? Isso é estilo ruim (provavelmente)? Em caso afirmativo, o rustfmt pode corrigir isso automaticamente?

A precedência óbvia coloca await _somewhere_ abaixo de ? . Não tenho certeza de onde exatamente, embora esses detalhes provavelmente não importem muito.

let res = await? (client
    .get("url")
    .send())
    .json();

Você sabe o que isso faz à primeira vista? O rustfmt pode colocá-lo em um estilo útil que não desperdice muito espaço vertical e horizontal automaticamente?

Onde as palavras-chave do Postfix cairiam nisso? Provavelmente, método de palavra-chave com chamadas de método e campo de palavra-chave com expressões de campo, mas não tenho certeza de como os outros devem ser vinculados. Que opções levam ao mínimo de configurações possíveis onde await recebe um "argumento" surpreendente?

Para esta comparação, suspeito que os "delimitadores obrigatórios" (o que chamei de Função de palavra-chave no resumo ) ganham facilmente, pois seriam equivalentes a uma chamada de função normal.

@ CAD97 Para ser claro, lembre-se de que .json() também é um futuro (pelo menos em reqwests ).

let res = await await client
    .get("url")
    .send()?
    .json()?;

let res = await? await? (client
    .get("url")
    .send())
    .json();

Quanto mais eu brinco com a conversão de expressões ferrugem complexas (mesmo aquelas com apenas a necessidade de 1 await, no entanto, observe que em minha base de código de mais de 20.000 + quase todas as expressões assíncronas são um await, seguido diretamente por outro await), mais eu não gosto prefixo para Rust.

Isso é _tudo_ por causa do operador ? . Nenhuma outra linguagem tem um operador de fluxo de controle postfix _and_ await que são essencialmente sempre pareados em código real.

Minha preferência ainda é o campo Postfix . Como um operador de controle postfix, sinto que ele precisa do agrupamento visual estreito que future.await fornece em future await . E comparando com .await()? , eu prefiro como .await? parece _estranho_, então será _notado_ e os usuários não assumirão que é uma função simples (e, portanto, não perguntarão por que o UFCS não funciona) .

Como mais um ponto de dados a favor do postfix, quando ele estiver estabilizado, um rustfix ir de await!(...) para o que decidirmos seria muito apreciado. Não vejo como qualquer coisa, exceto a sintaxe pós-fixada, poderia ser traduzida de forma inequívoca sem envolver coisas em ( ... ) desnecessariamente.

Acho que primeiro devemos responder à pergunta "queremos encorajar o uso de await em contextos de encadeamento?". Eu acredito que a resposta predominante é "sim", então se torna um forte argumento para variantes pós-fixadas. Embora await!(..) seja o mais fácil de adicionar, acredito que não devemos repetir a história de try!(..) . Também, pessoalmente, discordo do argumento de que "o encadeamento oculta uma operação potencialmente custosa", já temos muitos métodos de encadeamento que podem ser _muito_ pesados, portanto, o encadeamento não implica preguiça.

Embora o prefixo await palavra-chave seja o mais familiar para usuários vindos de outras línguas, não acho que devemos tomar nossa decisão com base nele e, em vez disso, devemos nos concentrar em longo prazo, ou seja, usabilidade, conveniência e legibilidade . @withoutboats falou sobre "orçamento de familiaridade", mas acredito fortemente que não devemos introduzir soluções abaixo do ideal apenas por questão de familiaridade.

Agora, provavelmente não queremos duas maneiras de fazer a mesma coisa, então não devemos introduzir as variantes pós-fixada e pré-fixada. Então, digamos que restringimos nossas opções para variantes pós-fixadas.

Primeiro, vamos começar com fut await . Não gosto dessa variante, porque ela vai bagunçar seriamente a forma como os humanos analisam o código e será uma fonte constante de confusão durante a leitura do código. (Não se esqueça de que o código é principalmente para leitura)

Próximos fut.await , fut.await() e fut.await!() . Acho que a variante mais consistente e menos confusa será a macro postfix. Não acho que vale a pena introduzir uma nova entidade de "função de palavra-chave" ou "método de palavra-chave" apenas para salvar alguns caracteres.

Por último, variantes baseadas em sigilos: fut@await e fut@ . Não gosto da variante fut@await , se introduzirmos o sigilo, por que se preocupar com a parte await ? Temos planos para extensões futuras fut@something ? Se não, simplesmente parece redundante. Então eu gosto da variante fut@ , ela resolve os problemas de precedência, o código se torna fácil de entender, escrever e ler. Os problemas de visibilidade podem ser resolvidos realçando o código. Não será difícil explicar esse recurso como "@ for await". Obviamente, a maior desvantagem é que pagaremos por esse recurso com um "orçamento de sigilo" muito limitado, mas considerando a importância do recurso e a frequência com que será usado em bases de código assíncronas, acredito que valerá a pena a longo prazo . E, claro, podemos traçar certos paralelos com ? . (Embora tenhamos que estar preparados para piadas Perl dos críticos de Rust)

Concluindo: na minha opinião, se estamos prontos para sobrecarregar o "orçamento de sigilo", devemos ir com fut@ , e se não com fut.await!() .

Ao falar sobre familiaridade, não acho que devamos nos preocupar muito com a familiaridade com JS / Python / C #, uma vez que Rust está em um nicho diferente e já tem uma aparência diferente em muitas coisas. Fornecer sintaxe semelhante a essas linguagens é uma meta de curto prazo e de baixa recompensa. Ninguém selecionará Ferrugem apenas para usar palavras-chave familiares quando, por baixo do capô, ele funcionar de maneira completamente diferente.

Mas a familiaridade com Go importa, já que Rust está em um nicho semelhante e até mesmo por filosofia está mais próximo de Go do que de outras linguagens. E apesar de todo o ódio preconceituoso, um dos pontos mais fortes de ambos é que eles não copiam recursos cegamente, mas implementam soluções que realmente têm razão para.

IMO, neste sentido <-- sintaxe é mais forte aqui

Com tudo isso, vamos lembrar que expressões Rust podem resultar em vários métodos encadeados. A maioria das línguas tende a não fazer isso.

Eu gostaria de lembrar a experiência da equipe dev C #:

A principal consideração contra a sintaxe do C # é a precedência de operador await foo?

Isso é algo que sinto que posso comentar. Nós pensamos muito sobre precedência com 'esperar' e tentamos muitos formulários antes de definir o formulário que queríamos. Uma das coisas principais que descobrimos foi que, para nós e para os clientes (internos e externos) que queriam usar esse recurso, raramente as pessoas realmente queriam 'encadear' algo além de sua chamada assíncrona.

A tendência das pessoas de querer 'continuar' com o 'esperar' dentro de uma expr era rara. Ocasionalmente vemos coisas como (await expr) .M (), mas parecem menos comuns e menos desejáveis ​​do que a quantidade de pessoas que aguardam expr.M ().

e

É também por isso que não escolhemos nenhuma forma 'implícita' para 'esperar'. Na prática, era algo sobre o qual as pessoas queriam pensar com muita clareza e que queriam primeiro e centralizado em seu código, para que pudessem prestar atenção nele. Curiosamente, mesmo anos depois, essa tendência se manteve. isto é, às vezes, muitos anos depois, lamentamos que algo seja excessivamente prolixo. Alguns recursos são bons assim no início, mas uma vez que as pessoas se sintam confortáveis ​​com eles, são mais adequados para algo mais simples. Esse não foi o caso com 'esperar'. As pessoas ainda parecem realmente gostar da natureza pesada dessa palavra-chave e da precedência que escolhemos.

É um bom ponto contra sigilo em vez de palavra (chave) dedicada.

https://github.com/rust-lang/rust/issues/50547#issuecomment -388939886

Você realmente deve ouvir os caras com milhões de usuários.

Então você não quer encadear nada, você só quer ter vários await , e minha experiência é a mesma. Escrevendo código async/await por mais de 6 anos, e nunca quis esse recurso. A sintaxe do Postfix parece realmente estranha e é considerada para resolver uma situação que provavelmente nunca acontecerá. Async chamada de

A tendência das pessoas de querer 'continuar' com o 'esperar' dentro de uma expr era rara. Ocasionalmente vemos coisas como (await expr) .M (), mas parecem menos comuns e menos desejáveis ​​do que a quantidade de pessoas que aguardam expr.M ().

Isso parece uma análise a posteriori. Talvez uma das razões pelas quais eles não continuem é porque é extremamente estranho fazê-lo na sintaxe de prefixo (comparável a não querer try! várias vezes em uma instrução porque isso permanece legível pelo operador ? ). O que foi dito acima considera principalmente (até onde posso dizer) a precendência, não a posição. E eu gostaria de lembrar a você que C # não é Rust, e os membros do trait podem mudar um pouco o desejo de chamar métodos nos resultados.

@ I60R ,

1. Acho que a familiaridade é importante. Rust é uma linguagem relativamente nova e as pessoas migrarão de outras línguas e, se o Rust parecer familiar, será mais fácil para eles tomar a decisão de escolher o Rust.
2. Não sou muito divertido com métodos de encadeamento - é muito mais difícil depurar cadeias longas e acho que o encadeamento está apenas complicando a legibilidade do código e pode ser permitido apenas como opção adicional (como macros .await!() ). A forma de prefixo forçará os desenvolvedores a extrair o código em métodos em vez de encadear, como:

let resp = await client.get("http://api")?;
let body: MyResponse = await resp.into_json()?;

em algo assim:

let body: MyResponse = await client.get_json("http://api")?;

Isso parece uma análise a posteriori. Talvez um dos motivos pelos quais eles não continuem seja porque é extremamente estranho fazer isso na sintaxe de prefixo. A descrição acima considera apenas a precendência, não a posição. E eu gostaria de lembrar a você que C # não é Rust, e os membros do trait podem mudar um pouco o desejo de chamar métodos nos resultados.

Não, trata-se de experimentos de equipe C # internos quando tinha formulários prefixo / postfix / implícito. E estou falando sobre minha experiência, que não é apenas um hábito em que não consigo ver os profissionais do formulário postfix.

@mehcode Seu exemplo não me motiva. reqwest decide conscientemente fazer o ciclo de solicitação / resposta inicial e o tratamento subsequente da resposta (fluxo do corpo) em processos simultâneos separados, portanto, eles devem ser esperados duas vezes, como mostra @andreytkachenko .

reqwest poderia expor totalmente as seguintes APIs:

let res = await client
    .get("url")
    .json()
    .send();

ou

let res = await client
    .get("url")
    .send()
    .json();

(O último sendo um açúcar simples acima de and_then ).

Acho preocupante que muitos dos exemplos de postfix aqui usem essa cadeia como exemplo, já que reqwest hyper s a melhor decisão de API é manter essas coisas separadas.

Eu honestamente acredito que a maioria dos exemplos de espera de postfix aqui devem ser reescritos usando combinadores (e açúcar, se necessário) ou ser mantidos em operações semelhantes e aguardados várias vezes.

@andreytkachenko

A forma de prefixo forçará os desenvolvedores a extrair o código em métodos em vez de encadear, como:

Isso é bom ou ruim? Para casos em que há N métodos, cada um deles podendo resultar em M acompanhamentos, o desenvolvedor deve fornecer N * M métodos? Eu, pessoalmente, gosto de soluções composíveis, mesmo que sejam um pouco mais longas.

em algo assim:

let body: MyResponse = await client.get_json("http://api")?;

let body: MyResponse = client.get("http://api").await?.into_json().await?;

@Pzixel

Não acho que em C # você obteria tantos códigos encadeados / funcionais quanto em Rust. Ou eu estou errado? Isso torna as experiências de desenvolvedores / usuários C # interessantes, mas não necessariamente aplicáveis ​​ao Rust. Eu gostaria que pudéssemos contrastar com Ocaml ou Haskell.

Eu acho que a causa raiz da discordância é que alguns de nós gostamos de um estilo imperativo e outros funcional. E é isso. Rust oferece suporte a ambos, e ambos os lados do debate desejam que o assíncrono se encaixe bem na maneira como normalmente escrevem o código.

@dpc

Não acho que em C # você obteria tantos códigos encadeados / funcionais quanto em Rust. Ou eu estou errado? Isso torna as experiências de desenvolvedores / usuários C # interessantes, mas não necessariamente aplicáveis ​​ao Rust. Eu gostaria que pudéssemos contrastar com Ocaml ou Haskell.

LINQ e estilo funcional são muito populares em C #.

@dpc ,
se você é sobre legibilidade - acho que tanto código explícito - quanto melhor, e minha experiência diz que se os nomes de métodos / funções forem bem autodescritivos não é necessário fazer os acompanhamentos.

se você sobre overhead - o compilador Rust é bastante inteligente para embuti-los (de qualquer maneira, sempre temos #[inline] ).

@dpc

let body: MyResponse = client.get("http://api").await?.into_json().await?;

Minha sensação é que isso basicamente repete o problema da API de futuros: torna o encadeamento mais fácil, mas o tipo dessa cadeia se torna muito mais difícil de penetrar e depurar.

Esse mesmo argumento não se aplica ao? operador embora? Ele permite mais encadeamento e, portanto, torna a depuração mais difícil. Mas por que escolhemos? mais de tentar! então? E por que Rust prefere APIs com padrão de construtor? Portanto, Rust já fez um monte de escolhas favorecendo o encadeamento em APIs. E sim, isso pode tornar a depuração mais difícil, mas isso não deveria acontecer em um nível de lint - talvez um novo lint para clippy para correntes que são muito grandes? Eu ainda tenho que ver motivação suficiente para saber como esperar é diferente aqui.

Isso é bom ou ruim? Para casos em que há N métodos, cada um deles podendo resultar em M acompanhamentos, o desenvolvedor deve fornecer N * M métodos? Eu, pessoalmente, gosto de soluções composíveis, mesmo que sejam um pouco mais longas.

N e M não são necessariamente grandes e também nem todos podem ser de interesse / utilidade para extrair.

@andreytkachenko ,

1. Não concordo, a familiaridade é superestimada aqui. Ao migrar de outra linguagem, primeiro as pessoas buscariam a capacidade de fazer programação no estilo async-await , mas não exatamente com a mesma sintaxe. Se fosse implementado de maneira diferente, mas proporcionasse uma melhor experiência de programação, então se tornaria mais uma vantagem.

2. A incapacidade de depurar cadeias longas é uma limitação dos depuradores que não são do estilo do código. Sobre a legibilidade, acho que depende, e impor um estilo imperativo é desnecessariamente restritivo aqui. Se async chamadas de função ainda são chamadas de função, então é surpreendente não suportar encadeamento. E de qualquer maneira, <-- é um operador de prefixo com capacidade de usá-lo em cadeias de funções como opção adicional, como você disse

@skade Concordo.

Todos os exemplos com longas cadeias de espera são um cheiro de código. Eles poderiam ser resolvidos de maneira muito mais elegante com combinadores ou APIs atualizadas, em vez de criar essas máquinas de estado espaguete geradoras sob o capô. A sintaxe abreviada extrema é uma receita para depurar ainda mais difícil do que os futuros atuais.

Eu ainda sou um fã de ambos prefixo palavra-chave await e macro await!(...) / .await!() , em combinação com async e #[async] funções de gerador , conforme descrito em meu comentário aqui .

Se tudo correr corretamente, uma única macro provavelmente poderia ser criada para await! para lidar com prefixo e sufixo, e a palavra-chave await seria apenas uma palavra-chave dentro de async funções.

@skade ,
Para mim, uma grande desvantagem de usar combinadores em future é que eles esconderão async chamadas de função e seria impossível distingui-los de funções regulares. Quero ver todos os pontos que podem ser suspensos, pois é muito provável que sejam usados ​​dentro de cadeias de estilo construtor.

@ I60R depurar cadeias de chamadas longas não é totalmente um problema de depurador, porque o problema em escrever essas cadeias é obter a inferência de tipo correta. Dado que muitos desses métodos usam parâmetros genéricos e distribuem parâmetros genéricos, potencialmente vinculados a um encerramento, é um problema grave.

Não tenho certeza se tornar visíveis todos os pontos de suspensão é um objetivo do recurso. Isso cabe aos implementadores decidir. E é totalmente possível com todas as versões propostas da sintaxe await .

@novacrazy bom ponto, agora que você mencionou, como um ex-javascripter, eu NUNCA uso await chains, eu sempre usei blocos then

Eu acho que seria algo como

let result = (await doSomethingAsync()
          .then(|result| {
                     match result {
                          Ok(v) => doSomethingAsyncWithFirstResponse(v)
                          Err(e) => Future.Resolve(Err(e))
                      }
            }).then(|result| {
                  Ok(result.unwrap())
            })).unwrap();

que nem sei se é possível, preciso pesquisar futuros em Rust

@richardanaya isso é totalmente possível (sintaxe diferente).

Como o Box impl:

impl<T> Box<T> {
    #[inline]
    pub fn new(x: T) -> Box<T> {
        box x
    }
    ...
}

Podemos inserir uma nova palavra-chave await e o traço Await com este impl:

impl<T> Await for T {
    #[inline]
    pub fn await(self) -> T {
        await self
    }
    ...
}

E use await como método e também como palavra-chave:

let result = await foo();
first().await()?.second().await()?;

@richardanaya Concordo. Eu estava entre alguns dos primeiros desenvolvedores a adotar async / await para meu material de webdev há muitos anos, e o poder real veio da combinação de async / await com as Promises / Futures existentes. Além disso, mesmo o seu exemplo provavelmente poderia ser simplificado como:

let result = await doSomethingAsync()
                  .and_then(doSomethingAsyncWithFirstResponse);

let value = result.unwrap();

Se você tiver aninhados futuros ou resultados de futuros ou futuros de resultados, o combinador .flatten() pode simplificar ainda mais isso drasticamente. Seria péssimo desembrulhar e aguardar cada um manualmente.

@XX Isso é redundante e inválido. await só existe em funções async , e só pode funcionar em tipos que implementam Future / IntoFuture qualquer maneira, então não há necessidade de um novo traço.

@novacrazy, @richardanaya

eles poderiam ser resolvidos de forma muito mais elegante com combinadores ou APIs atualizadas, em vez de criar essas máquinas de estado espaguete geradoras sob o capô. A sintaxe abreviada extrema é uma receita para depurar ainda mais difícil do que os futuros atuais.

@novacrazy bom ponto, agora que você mencionou, como um ex-javascripter, eu NUNCA uso await chains, eu sempre usei blocos then

Os combinadores têm propriedades e poderes totalmente diferentes em Rusts async / await, por exemplo, em relação a empréstimos em pontos de rendimento. Você não pode escrever combinadores com segurança que tenham as mesmas habilidades dos blocos assíncronos. Vamos deixar a discussão do combinador fora deste tópico, pois não é útil.

@ I60R

Para mim, uma grande desvantagem de usar combinadores no futuro é que eles esconderão as chamadas de função assíncronas e seria impossível distingui-las das funções regulares. Quero ver todos os pontos que podem ser suspensos, pois é muito provável que sejam usados ​​dentro de cadeias de estilo construtor.

Você não pode ocultar pontos de suspensão. A única coisa que os combinadores permitem é a criação de outros futuros. Em algum momento, eles devem ser aguardados.

Lembre-se de que C # não tem o problema de a maioria dos códigos que usam um prefixo await combiná-lo com o postfix (já existente) ? operador. Em particular, questões sobre precedência e a estranheza geral de ter dois "decoradores" semelhantes aparecem em lados opostos de uma expressão.

@ Matthias247 Se você precisar emprestar dados, com certeza, sinta-se à vontade para usar várias instruções await . No entanto, muitas vezes você simplesmente precisa mover os dados, e os combinadores são perfeitamente válidos para isso e têm o potencial de compilar para um código mais eficiente. Às vezes, sendo totalmente otimizado.

Novamente, o verdadeiro poder está em combinar as coisas. Não existe uma maneira certa de fazer coisas tão complicadas como esta. Em parte, é por isso que considero todo esse bicicletário de sintaxe exatamente isso, se não vai ajudar os novos usuários vindos de outra linguagem e ajudar a criar código de fácil manutenção, desempenho e legibilidade . 80% das vezes duvido que sequer toque em async / await não importa qual seja a sintaxe, apenas para fornecer APIs mais estáveis ​​e com desempenho usando futuros simples.

Nesse sentido, a palavra-chave de prefixo await e / ou macro mista await!(...) / .await!() são as opções mais legíveis, familiares e fáceis de depurar.

@andreytkachenko

Vi sua postagem e concordo totalmente, aliás, agora que reflito sobre "familiaridade", acho que existem dois tipos de familiaridade:

1. Fazendo a sintaxe de await parecer com linguagens semelhantes que usam muito await. Javascript é muito grande aqui e muito relevante para nossos recursos WASM como uma comunidade.

2. O segundo tipo de familiaridade é fazer com que o código pareça familiar para desenvolvedores que só trabalham com código síncrono. Acho que o maior aspecto do await é fazer o código assíncrono LOOK síncrono. Na verdade, isso é uma coisa que o javascript realmente faz de errado é que ele é normalizado em cadeias longas que parecem totalmente estranhas aos desenvolvedores principalmente síncronos.

Uma coisa que eu ofereceria dos meus dias de assíncrono em javascript, o que era muito mais útil para mim como desenvolvedor em retrospecto, era a capacidade de agrupar promessas / futuros. Promise.all (p1 (), p2 ()) para que eu pudesse facilmente paralisar o trabalho. O encadeamento then () sempre foi apenas um eco da promessa do Javascript do passado, mas muito arcaico e desnecessário agora que penso nisso.

Eu ofereceria talvez a ideia de esperar. "Tente fazer as diferenças entre o código assíncrono e o código de sincronização o mínimo possível"

@novacrazy A função assíncrona retorna um tipo impl Future , certo? O que nos impede de adicionar o método await a Future trait? Assim :

pub fn await(self) -> Self::Output {
    await self
}
...

@XX Pelo que entendi, async funções em Rust são transformadas em máquinas de estado usando geradores. Este artigo é uma boa explicação. Portanto, await precisa de uma função async para funcionar, de forma que o compilador possa transformar ambos corretamente. await não pode funcionar sem a parte async .

Future tem um wait método, que é semelhante ao que você sugere, mas bloqueia o segmento atual.

@skade ,

Mas como o estilo do código pode afetar a inferência de tipo? Não consigo ver diferença no mesmo código que é escrito em estilo encadeado e imperativo. Os tipos devem ser exatamente iguais. Se o depurador não é capaz de descobri-los, isso definitivamente é um problema no depurador, não no código.

@skade , @ Matthias247 , @XX

Com os combinadores, você terá exatamente um ponto suspenso marcado no início da cadeia de funções. Todos os outros estariam implícitos dentro. Esse é exatamente o mesmo problema de pegar mut implícito, o que, pessoalmente, para mim foi um dos maiores pontos de confusão em Rust. Algumas APIs retornariam futuros, enquanto outras retornariam resultados de futuros - eu não quero isso. Os pontos de suspensão devem ser explícitos, se possível, e a sintaxe adequadamente combinável incentivaria que

@ I60R let ligações são pontos de junção para digitar inferência e ajudar no relatório de erros.

@novacrazy

Portanto, o await precisa de uma função assíncrona para funcionar

Isso pode ser expresso em tipo de retorno? Por exemplo, que o tipo de retorno é impl Future + Async , em vez de impl Future .

@skade Eu sempre pensei que . na sintaxe de chamada de método serve exatamente para o mesmo propósito

@dpc

Não acho que em C # você obteria tantos códigos encadeados / funcionais quanto em Rust. Ou eu estou errado? Isso torna as experiências de desenvolvedores / usuários C # interessantes, mas não necessariamente aplicáveis ​​ao Rust. Eu gostaria que pudéssemos contrastar com Ocaml ou Haskell.

você obtém tanto quanto Rust. Observe qualquer código LINQ e você o verá.

O código assíncrono típico se parece com isto:

async Task<List<IGroping<int, PageMetadata>>> GetPageMetadata(string url, DbSet<Page> pages)
{
    using(var client = new HttpClient())
    using(var r = await client.GetAsync(new Uri(url)))
    {
        var content = await r.Content.ReadAsStringAsync();
                return await pages
                   .Where(x => x.Content == content)
                   .Select(x => x.Metadata)
                   .GroupBy(x => x.Id)
                   .ToListAsync();
    }
}

Ou, mais geral

let a = await!(service_a);
let b = await!(some_method_on(a, some, other, params));
let c = await!(combine(somehow, a, b));

Você não encadeia chamadas, atribui a uma variável e usa de alguma forma. Isso é especialmente verdadeiro quando você lida com o tomador de empréstimo.

Posso concordar que você pode encadear futuros em uma única situação. Quando você deseja lidar com um erro que pode ocorrer durante a chamada. por exemplo, let a = await!(service_a)? . Esta é a única situação em que a alternativa postfix é melhor. Eu poderia ver que isso se beneficia, mas não acho que supere todos os contras.

Outra razão: o que é sobre impl Add for MyFuture { ... } e let a = await a + b; ?

Gostaria de lembrar sobre a RFC de atribuição de tipo generalizada no contexto da palavra-chave await do postfix. Isso permitiria o seguinte código:

let x = (0..10)
    .map(some_computation)
    .collect() : Result<Vec<_>, _>
    .unwrap()
    .map(other_computation) : Vec<usize>
    .into() : Rc<[_]>;

Muito parecido com a palavra-chave espera do postfix:

let foo = alpha() await?
    .beta await
    .some_other_stuff() await?
    .even_more_stuff() await
    .stuff_and_stuff();

Com as mesmas desvantagens quando formatado incorretamente:

foo.iter().map(|x| x.bar()).collect(): Vec<_>.as_ref()

client.get("https://my_api").send() await.unwrap().json() await.unwrap()

Acho que se engolirmos a pílula da RFC de atribuição de tipo, devemos engolir fut await para manter a consistência.

BTW, você sabia que esta é uma sintaxe válida:

fn main() {
    println
    !("Hello, World!");
}

Mesmo assim, não vi nenhuma ocorrência disso no código real.

Permita-me divagar um pouco. Acho que devemos dar macros postfix, como sugerido por @BenoitZugmeyer , outro pensamento. Isso poderia ser feito como expr!macro ou como expr@macro , ou talvez até expr.macro!() . Acho que a primeira opção seria preferível. Não tenho certeza se eles são uma boa ideia, mas se quisermos extrair um conceito geral e não uma solução ad-hoc enquanto ainda temos

Tenha em mente que mesmo se fizéssemos await uma macro postfix, ela ainda seria mágica (como compile_error! ). No entanto, @jplatte e outros já estabeleceram que isso não é um problema.

Como eu faria se fôssemos seguir esse caminho, primeiro estabeleceria exatamente como as macros pós-fixadas funcionariam, então permitiria apenas await como uma macro pós-fixada mágica e depois permitiria as próprias macros pós-fixadas.

Lexing

Quanto a lexing / análise, isso pode ser um problema. Se olharmos para expr!macro , o compilador pode pensar que existe uma macro chamada expr! e então existem algumas letras inválidas macro depois disso. No entanto, expr!macro deve ser possível para lex por um lookahead de um, e algo se torna uma macro postfix quando há um expr seguido por um ! , seguido diretamente por identifier . Não sou um desenvolvedor de linguagem e não tenho certeza se isso torna o léxico excessivamente complexo. Vou apenas assumir que as macros postfix podem assumir a forma de expr!macro .

Macros postfix seriam úteis?

No topo da minha cabeça, eu criei esses outros casos de uso para macros pós-fixadas. Eu não acho que todos eles podem ser implementados por macros personalizadas, então não tenho certeza se esta lista é muito útil.

• stream!await_all : para aguardar transmissões
• option!or_continue : quando option for Nenhum, continue o loop
• monad!bind : por fazer =<< sem vinculá-lo a um nome

stream!await_all

Isso nos permite não apenas esperar por futuros, mas também por fluxos.

event_stream("ws://some.stock.exchange/usd2eur")
    .and_then(|exchange_response| {
        let exchange_rate = exchange_response.json()?;
        stream::once(UpdateTickerAction::new(exchange_rate.value))
    })

seria equivalente a (em um bloco async -stream-esque):

let exchange_rate = event_stream("ws://some.stock.exchange/usd2eur")
    !await_all
    .json()?;

UpdateTickerAction::new(exchange_rate.value)

option!or_continue

Isso nos permite desembrulhar uma opção e, se for None , continuar o loop.

loop {
    let event = match engine.event() {
        Some(event) => event,
        None => continue,
    }
    let button = match event.button() {
        Some(button) => button,
        None => continue,
    }
    handle_button_pressed(button);
}

seria equivalente a:

loop {
    handle_button_pressed(
        engine.event()!or_continue
            .button()!or_continue
    );
}

monad!bind

Este nos permitiria obter mônadas de uma forma bastante rústica (isto é, centrada na expressão). Rust ainda não tem nada parecido com mônadas e não estou convencido de que sejam adicionadas ao Rust. No entanto, se eles forem adicionados, essa sintaxe pode ser útil.

Eu peguei o seguinte a partir daqui .

nameDo :: IO ()
nameDo = do putStr "What is your first name? "
            first <- getLine
            putStr "And your last name? "
            last <- getLine
            let full = first ++ " " ++ last
            putStrLn ("Pleased to meet you, " ++ full ++ "!")

seria equivalente a:

do {
    putStr("What is your first name? ")!bind;
    let first = getLine()!bind;
    putStr("And your last name? ")!bind;
    let last = getLine()!bind;
    let full = first + " " + &last
    putStrLn("Pleased to meet you, " + &full + "!")!bind;
}

Ou, mais alinhado, com menos let s:

do {
    putStr("What is your first name? ")!bind;
    let first = getLine()!bind;
    putStr("And your last name? ")!bind;
    putStrLn(
        "Pleased to meet you, " + &first + " " + &getLine()!bind + "!"
    )!bind;
}

Avaliação

Estou muito dividido nisso. A parte matemática do meu cérebro quer encontrar uma solução generalizada para await , e macros pós-fixadas podem ser uma maneira de alcançá-las. A parte pragmática do meu cérebro pensa: Por que se preocupar em fazer uma linguagem cujo macrossistema ninguém entende ainda mais complicada.

No entanto, de ? e await , temos dois exemplos de operadores Postfix superúteis. E se encontrarmos outros que desejamos adicionar no futuro, talvez semelhantes aos que mencionei? Se os generalizamos, podemos adicioná-los ao Rust naturalmente. Do contrário, teríamos que criar outra sintaxe a cada vez, o que provavelmente aumentaria o volume da linguagem mais do que as macros pós-fixadas.

O que é que vocês acham?

@EyeOfPython

Tive uma ideia muito semelhante e tenho certeza de que macros postfix em Rust é questão de tempo.
Estou pensando nisso todas as vezes ao lidar com o fatiamento de ndarray :

let view = array.slice(s![.., ..]);

mas muito melhor seria

let view = array.slice![.., ..];
// or like you suggested
let view = array!slice[.., ..];
// or like in PHP
let view = array->slice![.., ..];

e muitos combinadores podem desaparecer, como aqueles com _with ou _else postfixes:

opt!unwrap_or(Error::new("Error!"))?; //equal to .unwrap_or_else(||Error::new("Error!"));

@EyeOfPython @andreytkachenko macros postfix não são atualmente um recurso no Rust e o IMHO precisaria de uma fase de implementação RFC + FCP + completa.

Esta não é uma discussão RFC, mas uma discussão de uma RFC aceita que precisa ser implementada.

Por esse motivo, não acho prático discuti-los aqui ou propô-los para sintaxe assíncrona. Isso atrasaria ainda mais o recurso massivamente.

Para refrear essa discussão já massiva, eu acho que _não_ é útil discuti-los aqui, eles podem ser vistos fora do assunto discutido.

Apenas um pensamento: embora este tópico seja especificamente para await , acho que teremos a mesma discussão para yield expressões mais adiante, que também podem ser encadeadas. Na medida em que eu prefiro ver uma sintaxe que possa ser generalizada, seja como for.

Minhas razões para não usar macros aqui:

1. As macros são fornecidas para coisas específicas do domínio e usá-las de qualquer forma que altere o fluxo de controle dos programas ou emule os recursos básicos da linguagem é um exagero
2. As macros Postfix seriam imediatamente utilizadas para implementar operadores personalizados ou outros recursos de linguagem esotérica que levam a código incorreto
3. Eles desencorajariam o desenvolvimento de recursos de linguagem adequados:
   
   
   
   • stream.await_all é um caso de uso perfeito para combinador
   
   
   • option.or_continue e substituir _else combinadores é um caso de uso perfeito para o operador de coalescência nulo
   
   
   • monad.bind é o caso de uso perfeito para if-let correntes
   
   
   • ndarray slicing é o caso de uso perfeito para const genéricos
   
   
4. Eles iriam colocar em questão o operador ? já implementado

@collinanderson

que da mesma forma poderia ser acorrentado

Por que diabos você acha que eles podem ser acorrentados? zero ocorrências no código real, assim como println exemplo acima.

@Pzixel É provável que eventualmente Generator::resume assuma um valor e, portanto, yield expr terá um tipo diferente de () .

@vlaff Não vejo claramente um argumento para await ter que ser consistente com a atribuição de tipo. São coisas muito diferentes.

Além disso, a atribuição de tipo é outro dos recursos que são tentados repetidamente, não há garantia de que _este_ será executado. Embora eu não queira me opor a isso, TA é um futuro RFC e esta é uma discussão sobre um recurso aceito com uma sintaxe já proposta.

Lendo os muitos comentários, para adicionar mais resumo sobre por que esperar! (...) parece um caminho muito ideal:

1. parece o mais familiar ao código existente porque as macros são familiares
2. há trabalho existente que usa o await! (...) https://github.com/alexcrichton/futures-await e pode ajudar a reduzir a reescrita de código
3. uma vez que macros postfix não estão na mesa, podem nunca fazer parte da linguagem e "aguarde!" em um contexto fora do padrão não parece ser uma possibilidade de acordo com os RFCs
4. dá à comunidade mais tempo para considerar a direção de longo prazo após o uso estável e generalizado, ao mesmo tempo em que fornece algo que não está totalmente fora do normal (por exemplo, tente! ())
5. poderia ser usado como um padrão semelhante para o rendimento futuro! () até descobrirmos um caminho oficial que poderia satisfazer o await e o yield
6. o encadeamento pode não ser tão valioso quanto se espera e a clareza provavelmente será ainda melhorada por ter várias esperas em várias linhas
7. nenhuma mudança teria que acontecer para realçadores de sintaxe IDE
8. pessoas de outras línguas provavelmente não serão prejudicadas por uma macro await! (...) depois de ver outros usos de macro (menos sobrecarga cognitiva)
9. é provavelmente o caminho de menor esforço de todos os caminhos para avançar para a estabilização

aguardam! macro já está aqui, a questão é sobre encadeamento.

Quanto mais eu penso sobre isso, mais o postfix parece bom para mim. Por exemplo:

let a = foo await;
let b = bar await?;
let c = baz? await;
let d = booz? await?;
let e = kik? + kek? await? + kuk? await?;
// a + b is `impl Add for MyFuture {}` which alises to `a.select(b)`

Permite aninhamento de qualquer nível e pode ser facilmente lido. Funciona perfeitamente com ? e possíveis futuros operadores. Parece um pouco estranho para os novatos, mas o lucro da gramática pode superá-lo.

O principal motivo é que await deve ser uma palavra-chave separada, não uma chamada de função. É muito importante, por isso deve ter seu próprio destaque e lugar no texto.

@Pzixel , @HeroicKatora , @skade

Veja por exemplo as expressões Python yield e yield from : lá, a função externa pode fornecer um valor que se tornará o resultado de yield quando o gerador for reiniciado. Isso é o que @valff significa e não tem nada a ver com as atribuições de tipo. Portanto, yield também terá um tipo diferente de ! ou () .

Do ponto da co-rotina, yield e await suspendem e podem (eventualmente) retornar um valor. Na medida em que são apenas 2 faces da mesma moeda.

E para descartar outra possibilidade de sintaxe, _square-brackets-with-keyword_, em parte para destacar isso (usando yield para o destaque de sintaxe):

let body: MyResponse = client.get("http://api").send()[yield]?.into_json()[yield]?

"palavra-chave postfix" faz mais sentido para mim. postfix com um caractere diferente de espaço em branco separando a expressão futura e await também faz sentido para mim, mas não '.' já que isso é para métodos e await não é um método. No entanto, se você quiser await como uma palavra-chave de prefixo, gosto da sugestão @XX de uma Característica ou método que apenas chama await self para aqueles que desejam encadear um monte de coisas juntas (embora provavelmente não poderia nomear o método await ; apenas wait serviria, embora eu acho). Pessoalmente, eu provavelmente acabaria fazendo um await-per-line e não encadearia tanto porque acho cadeias longas menos legíveis, então prefixo ou pós-fixo funcionaria para mim.

[editar] Esqueci que wait já existe e bloqueia o futuro, então elimine esse pensamento.

@roland estou me referindo especificamente a isso, que discute as atribuições de tipo: https://github.com/rust-lang/rust/issues/57640#issuecomment -456023146

@rolandsteiner então você escreve

let body: MyResponse = client.get("http://api").send() await?.into_json() await?;

Quando eu escreveria como:

let response = client.get("http://api").send() await?;
let body: MyResponse = response.into_json() await?;

@skade Oh, você quis dizer um comentário diferente do que eu pensei, desculpe. : stick_out_tongue:

@Pzixel É provável que eventualmente Generator::resume assuma um valor e, portanto, yield expr terá um tipo diferente de () .

Portanto, yield também terá um tipo diferente de ! ou () .

@valff , @rolandsteiner Acho improvável que yield retorne o valor de retomada, que é difícil de se ajustar em uma linguagem tipada estaticamente sem tornar a sintaxe do gerador e / ou característica irritante de trabalhar. O protótipo original com argumentos de currículo usava a palavra-chave gen arg para se referir a este argumento, algo assim é muito mais provável de funcionar bem IMO. Desse ponto de vista, yield ainda retornará () portanto, não deve afetar muito a discussão de await .

Acho que await deve ser um operador de prefixo, porque async é (e espero que yield seja um prefixo também). Ou então, use-o como um método regular, usado na posição postfix.

No entanto, eu não entendo toda a história de motociclismo aqui: por que considerar uma palavra-chave postfix onde nenhum outro de Rust a tem? Isso tornaria a linguagem tão estranha.

Além disso, encadeando futuros, eu entendo por que poderia ser interessante. Mas o encadeamento o espera? O que isso significa? Um futuro que retorna um novo futuro? É realmente um idioma tão comum que queremos que Rust tenha esse idioma como cidadão de primeira classe? Se realmente nos importamos com isso, acho que devemos:

1. Vá para o método (ou seja, foo.await() ). Isso não introduz uma palavra-chave postfix estranha e todos nós sabemos o que significa. Nós também podemos nos conectar com isso.
2. Se realmente queremos uma palavra-chave / loloperator, podemos resolver essa questão mais tarde.

Além disso, para dar minha opinião pessoal, odeio o await na posição da palavra-chave postfix.

O prefixo await é usado em outros idiomas por uma razão - ele corresponde ao idioma natural. Você não diz "Eu irei esperar sua chegada". Embora tenha escrito JavaScript, posso ser um pouco tendencioso.

Também direi que considero await -chaining superestimado. O valor de async/await sobre combinadores futuros é que ele permite escrever código assíncrono sequencialmente, utilizando as construções de linguagem padrão, como if , match , etc. Você vai querer quebrar suas esperas de qualquer maneira.

Não vamos inventar muita sintaxe mágica para async/await , é apenas uma pequena parte da linguagem. A sintaxe do método proposto (ou seja, foo.await() ) é IMO muito ortogonal às chamadas de método normais e parece muito mágica. A máquina proc-macro está instalada, por que não disfarçá-la atrás dela?

Que tal usar a palavra-chave await em vez de async na definição da função? Por exemplo:

await fn foo(future: impl Future<Output = i32>) -> i32 {
    future
}

Este await fn só pode ser chamado no contexto async :

async {
    let n = foo(bar());
}

E desugar para let n = (await foo(bar())); .
Então, além da palavra-chave await , o traço Future poderia implementar o método await para usar await lógica na posição postfix, por exemplo:

async {
    let n = bar().awaited();
}

Além disso, alguém pode me explicar a relação com geradores? Estou surpreso que async / await sejam implementados antes dos geradores (mesmo estabilizados).

Os geradores async / await . Não há planos atuais para estabilizá-los e eles ainda exigem um RFC não experimental antes que possam ser. (Pessoalmente, eu adoraria tê-los estabilizados, mas parece provável que eles demorem pelo menos um ou dois anos, provavelmente não serão corrigidos até que async / await esteja estável e tenha havido alguma experiência com isso).

@XX Acho que você está quebrando a semântica de async se usar await na definição da função. Vamos seguir os padrões, não é?

@phaazon Você pode especificar com mais detalhes como isso quebra a semântica de async ?

A maioria das linguagens usa async para introduzir algo que vai ser assíncrono e await espera por isso. Então, ter await vez de async é meio estranho para mim.

@phaazon Não, não, mas adicionalmente. Exemplo completo:

async fn bar() -> i32 {
    5 // will be "converted" to impl Future<Output = i32>
}

await fn foo(future: impl Future<Output = i32>) -> i32 {
    future // will be "converted" to i32 in async context
}

async {
    let a = await bar(); // correct, a == 5
    let b = foo(bar()); // correct, b == 5
}

let c = foo(bar()); // error, can't call desugaring statement `await foo(bar())`

se for válido, então será possível implementar o método await para uso em uma cadeia:

async {
    let n = first().awaited()?.second().awaited()?;
    // let n = (await (await first())?.second())?;
}

Na minha opinião, não importa se o postfix await "parece" muito mágico e não está familiarizado com a linguagem. Se adotarmos a sintaxe do método .await() ou .await!() então é apenas uma questão de explicar que Future s tem um método .await() ou .await!() que você também pode usar para aguardá-los nos casos que fizerem sentido. Não é tão difícil de entender se você passar 5 minutos pensando sobre isso, mesmo que nunca tenha visto antes.

Além disso, se usarmos a palavra-chave prefix, o que nos impede de escrever uma caixa com o seguinte (pseudocódigo incompleto porque não tenho a infraestrutura para lidar com os detalhes agora):

trait AwaitChainable {
    fn await(self) -> impl Future;
}

impl<T: Future> AwaitChainable for T {
    fn await(self) -> impl Future {
        await self
    }
}

Dessa forma, podemos obter o Postfix Aguardar se quisermos. Quer dizer, mesmo que isso não seja possível e tenhamos que implementar postfix await magicamente pelo compilador, ainda podemos usar algo como o exemplo acima para explicar como ele geralmente funciona. Não seria difícil aprender.

@ivandardi Eu pensei o mesmo. Mas esta definição

fn await(self) -> impl Future {
    await self
}

não diz que a função pode ser chamada apenas no contexto async .

@XX Sim, como eu disse, ignore o pseudocódigo quebrado: PI atualmente não tem a infraestrutura para verificar como a sintaxe e os traços corretos devem ser escritos lá :( Imagine que eu escrevi o que o torna apenas chamável em assíncrono contextos.

@XX , @ivandardi Por definição, await só funciona em um contexto async . Portanto, isso é ilegal:

fn await(self) -> impl Future {
    await self
}

Deve ser

async fn await(self) -> impl Future {
    await self
}

Que só pode ser chamado em um contexto async como este:

await future.await()

O que anula todo o propósito.

A única maneira de fazer isso funcionar é mudar async completamente, o que está fora de questão.

@ivandardi Esta evolução da minha versão:

fn await(self) -> T { // How to indicate using in async-context only?
    await self
}

`` `ferrugem
aguarde fn aguarde (self) -> T {// Porque async já foi usado
espera-se
}

```rust
await fn await(self) -> T {
    self // remove excess await
}

@CryZe @XX Por que você está me vaiando? Eu estou certo.

@XX O que você está tentando fazer é alterar o significado de assíncrono e aguardar completamente (por exemplo, criar um contexto await que seja de alguma forma diferente de um contexto async ). Não acho que receberia muito suporte dos desenvolvedores de linguagem

@EyeOfPython Esta definição não funciona conforme o esperado:

async fn await(self) -> impl Future {
    await self
}

Mais provável:

#[call_only_in_async_context_with_derived_await_prefix]
fn await(self) -> impl Future {
    self
}

Estou rejeitando porque você ignorou que esta é uma pseudo sintaxe hipotética. Essencialmente, o ponto é que Rust poderia adicionar um traço especial como Drop e Copy que a linguagem entende, o que adiciona a habilidade de chamar .await () no tipo que então interage com o tipo assim como uma palavra-chave await faria. Além disso, votar é considerado irrelevante para RFCs, pois o objetivo é descobrir uma solução objetiva, não baseada em sentimentos subjetivos, como os visualizados por votos positivos / negativos.

Não entendo o que este código deve fazer. Mas isso não tem nada a ver com o modo como o async await funciona atualmente. Se você se preocupa com isso, por favor, mantenha-o fora deste tópico e escreva um RFC dedicado para ele.

@CryZe Esse tipo está disponível. Chama-se Futuro. E foi acordado há muito tempo que async / await é um mecanismo que visa APENAS transformar o código assíncrono. Não é uma notação de ligação geral.

@ivandari seu postfix

@ Matthias247 O que eles estavam tentando sugerir era uma maneira de fazer o postfix await ter a sintaxe de uma chamada de método. Dessa forma, o Rust não precisa introduzir novos símbolos arbitrários, como #, @ ou ... como fizemos com o? operador, e ainda parece bastante natural:

let result = some_operation().await()?.some_method().await()?;

Portanto, a ideia seria, de alguma forma, esperar ser um tipo especial de método no traço Future que o compilador vê da mesma forma que uma palavra-chave await normal (que você não precisa ter neste caso) e transformar o async código em um gerador a partir daí. Então você tem o fluxo de controle lógico adequado da esquerda para a direita em vez de esquerda direita esquerda com await some_future()? e não precisa introduzir novos símbolos estranhos.

(Então tl; dr: parece uma chamada de método, mas na verdade é apenas um postfix aguardando)

Algo que não vi mencionado explicitamente em consideração a uma sintaxe pós-fixada é a prevalência dos combinadores de erro e opção. Estes são os lugares onde a ferrugem é a mais diferente de todas as línguas que aguardam - em vez de rastreamentos automáticos, temos .map_err()? .

Em particular coisas como:

let result = await reqwest::get(..).send();
let response = result.map_err(|e| add_context(e))?;
let parser = await response.json();
let parsed = parser.map_err(|e| add_context(e))?;

é menos legível do que (não me importa qual sintaxe postfix é considerada):

let parsed = reqwest::get(..)
    .send() await
    .map_err(add_context)?
    .json() await
    .map_err(add_context)?;

_mesmo que_ esta formatação padrão tem mais linhas do que a abordagem multivariável. As expressões que não têm vários awaits parecem que devem ocupar menos espaço vertical com postfix-await.

Eu não escrevo código assíncrono agora, então estou falando por ignorância, desculpe continuar - se isso não é um problema na prática, então isso é excelente. Só não quero que o tratamento de erros adequado seja menos ergonômico, apenas para ser mais semelhante a outras linguagens que fazem o tratamento de erros de maneira diferente.

Sim, é isso que quero dizer. Seria o melhor dos dois mundos, permitindo às pessoas escolher se querem usar o prefixo ou o postfix para esperar, dependendo da situação.

@XX Se isso não puder ser expresso no código do usuário, teremos que recorrer ao compilador para implementar essa funcionalidade. Mas em termos de compreensão de como funciona o postfix, a explicação que postei anteriormente ainda funciona, mesmo que seja apenas um entendimento superficial.

@CryZe , @XX ,

À primeira vista, ele solta suavemente, mas absolutamente não corresponde à filosofia Rust. Mesmo o método sort em iteradores não retorna self e quebra a cadeia de chamada de método para tornar a alocação explícita. Mas você espera que algo não menos impactante seja implementado de maneira completamente implícita, indistinguível das chamadas de função regulares. Não há chances IMO.

Sim, é isso que quero dizer. Seria o melhor dos dois mundos, permitindo às pessoas escolher se querem usar o prefixo ou o postfix para esperar, dependendo da situação.

Por que isso deveria ser uma meta? A ferrugem não suporta isso para todos os outros fluxos de controle (por exemplo, break , continue , if , etc. também. Não há um motivo específico, além de "isso pode parece melhor em sua opinião particular.

Em geral, gostaria de lembrar a todos que await é muito especial e não uma invocação de método normal:

• Os depuradores podem se comportar de maneira estranha ao fazer uma espera, pois a pilha pode se desenrolar e ser restabelecida. Pelo que me lembro, demorou muito para que a depuração assíncrona funcionasse em C # e Javascript. E esses têm equipes pagas que trabalham em depuradores!
• Objetos locais que não passam pelos pontos de espera podem ser armazenados na pilha real do SO. Aqueles que não são devem ser movidos para o futuro gerado, o que no final fará a diferença na memória heap necessária (que é onde o futuro viverá).
• Os empréstimos em pontos de espera são a razão pela qual os futuros gerados precisam ser !Unpin e causam muitos transtornos com alguns dos combinadores e mecanismos existentes. Pode ser potencialmente possível gerar Unpin futuros a partir de async métodos que não contraem empréstimos em espera no futuro. No entanto, se await s forem invisíveis, isso nunca acontecerá.
• Pode haver outros problemas inesperados do verificador de empréstimo, que não são cobertos pelo estado atual de async / await.

@Pzixel @lnicola

Os exemplos que você dá para C # são totalmente imperativos, e nada como as cadeias longas de estilo funcional que costumamos ver no Rust. Essa sintaxe LINQ é apenas uma DSL e não é nada como foo().bar().x().wih_boo(x).camboom().space_flight(); Pesquisei um pouco no Google e os exemplos de código C # parecem 100% imperativos, assim como a maioria das linguagens de programação populares. É por isso que não podemos simplesmente pegar o que a Langue X fez, porque simplesmente não é a mesma coisa.

A notação de prefixo IMO se encaixa perfeitamente no estilo imperativo de codificação. Mas Rust suporta os dois estilos.

@skade

Não concordo com alguns comentários seus (e outros) sobre problemas com estilo funcional. Para ser breve - vamos apenas concordar que existem pessoas com forte preferência por um ou outro.

@ Matthias247 Não, há um motivo específico diferente de como ele parece bom. É porque Rust incentiva o encadeamento. E você pode dizer "oh, outros mecanismos de fluxo de controle não têm uma sintaxe postfix, então por que esperar ser especial?". Bem, essa é uma avaliação errada. Nós TEMOS fluxo de controle postfix. Eles são apenas internos aos métodos que chamamos. Option::unwrap_or é como fazer uma declaração de correspondência postfix. Iterator::filter é como fazer um postfix if. Só porque o fluxo de controle não faz parte da sintaxe de encadeamento em si, não significa que ainda não temos fluxo de controle postfix. Nesse ponto de vista, adicionar um postfix await seria realmente consistente com o que temos. Neste caso, poderíamos até ter algo mais semelhante a como funciona Iterator e em vez de apenas ter um postfix bruto aguardar, poderíamos ter alguns combinadores aguardar, como Future::await_or . De qualquer forma, ter o Postfix Aguardando não é apenas uma questão de aparência - é uma questão de funcionalidade e qualidade de vida. Caso contrário, ainda estaríamos usando a macro try!() , certo?

@dpc

Os exemplos que você dá para C # são totalmente imperativos, e nada como as cadeias longas de estilo funcional que costumamos ver no Rust. Essa sintaxe LINQ é apenas uma DSL e não é nada como foo (). Bar (). X (). Wih_boo (x) .camboom (). Space_flight (); Pesquisei um pouco no Google e os exemplos de código C # parecem 100% imperativos, assim como a maioria das linguagens de programação populares. É por isso que não podemos simplesmente pegar o que a Langue X fez, porque simplesmente não é a mesma coisa.

Não é verdade (você pode verificar qualquer estrutura, por exemplo, polly ), mas não vou discutir sobre isso. Eu vejo tantos códigos encadeados em ambas as linguagens. No entanto, na verdade existe algo que torna tudo diferente. E é chamado de Try trait. C # não tem nada semelhante a ele, então não supõe fazer nada além de await ponto. Se você obtiver uma exceção, ela será automaticamente encapsulada e gerada para o chamador.

Não é o caso do Rust, onde você deve usar manualmente o operador ? .

Se você tiver que ter algo além de await ponto, você deve criar o operador "combinado" await? , estender as regras de linguagem etc etc OU você pode apenas fazer o postfix de esperar e as coisas se tornarem mais naturais (exceto sintaxe um pouco estranha, mas quem se importa?).

Portanto, atualmente vejo o Postfix Aguardar como uma solução mais viável. A única sugestão que tenho deve ser uma palavra-chave dedicada separada por espaço, não await() ou await!() .

Acho que encontrei um bom motivo para justificar um método normal .await (). Se você pensar bem, não é diferente de qualquer outra forma de bloqueio. Você chama o método .await (), a execução do thread (possivelmente verde) é interrompida e, em algum ponto, o tempo de execução em execução retoma a execução do thread em algum ponto. Portanto, para todos os efeitos, quer você tenha um canal Mutex ou std como este:

let result = my_channel().recv()?.iter().map(...).collect();

ou um futuro como este:

let result = my_future().await()?.iter().map(...).collect();

não é diferente. Ambos bloqueiam a execução em seus respectivos recv () / await () e ambos encadeiam da mesma forma. A única diferença é que await () está possivelmente rodando em um executor diferente que não é o threading pesado do SO (mas pode muito bem ser no caso de um único executor threaded). Portanto, desencorajar grandes quantidades de encadeamento afeta exatamente a mesma coisa e provavelmente deve levar a um fiapo cortado real.

No entanto, meu ponto aqui é que, do ponto de vista da pessoa que está escrevendo este código, não há muita diferença em .recv () ou .await (), ambos são métodos que bloqueiam a execução e retornam assim que o resultado estiver disponível . Portanto, para todos os efeitos, pode ser praticamente um método normal e não requer uma palavra-chave completa. Não temos uma palavra-chave recv ou lock para o canal Mutex e std.

No entanto, o rustc obviamente quer transformar todo o código em um gerador. Mas isso é realmente semanticamente necessário do ponto de vista da linguagem? Tenho certeza de que seria possível escrever um compilador alternativo para rustc que implemente o await por meio do bloqueio de um thread de sistema operacional real (inserir um fn assíncrono precisaria gerar um thread e, em seguida, aguardar bloquearia esse thread). Embora fosse uma implementação extremamente ingênua e lenta, semanticamente se comportaria da mesma maneira. Portanto, o fato de que o rustc real se transforma em um gerador não é necessário semanticamente. Portanto, eu diria que rustc transformar a chamada para o método .await () em um gerador pode ser visto como um detalhe de implementação de otimização de rustc. Dessa forma, você pode justificar .await () sendo uma espécie de método completo e não uma palavra-chave completa, mas também ter rustc transformando tudo em um gerador.

@CryZe, ao contrário de .recv() , podemos interromper await com segurança de qualquer outro lugar no programa e então o código próximo a await não seria executado. Essa é uma grande diferença e essa é a razão mais valiosa pela qual não devemos fazer await implicitamente.

@ I60R Não é menos explícito do que esperar como palavra-chave. Você ainda pode destacá-lo da mesma maneira no IDE, se desejar. Ele apenas move a palavra-chave para a posição pós-fixada, onde eu diria que é realmente menos fácil de perder (pois é exatamente na posição onde a execução é interrompida).

Idéia maluca: implícita espera . Mudei para um tópico separado, porque este já está muito ocupado com a discussão de postfix vs prefix.

@CryZe

Acho que encontrei um bom motivo para justificar um método normal .await (). Se você pensar bem, não é diferente de qualquer outra forma de bloqueio.

Leia https://github.com/rust-lang/rust/issues/57640#issuecomment -456147515 novamente

@ Matthias247 Estes são pontos muito bons, parece que perdi aqueles.

Toda essa conversa sobre transformar o await em uma função, membro ou outro implícito é fundamentalmente inválido. Não é uma ação, é uma transformação.

O compilador, em um alto nível, seja por meio de uma palavra-chave ou macro, transforma expressões de espera em expressões de rendimento de gerador especiais, no local, contabilizando empréstimos e outras coisas ao longo do caminho.

Isso deve ser explícito.

Deve ser o mais aparente possível como uma palavra-chave ou, obviamente, gerar código com uma macro.

Métodos mágicos, características, membros, etc., são muito fáceis de interpretar mal e mal interpretar, especialmente para novos usuários.

A palavra-chave de prefixo await ou a macro de prefixo await parecem ser a maneira mais aceitável de fazer isso, o que faz sentido, já que muitas outras linguagens fazem dessa forma. Não precisamos ser especiais para torná-lo bom.

@novacrazy

Métodos mágicos, características, membros, etc., são muito fáceis de interpretar mal e mal interpretar, especialmente para novos usuários.

Você pode expandir isso? Mais especificamente na variante .await!() , se possível.

Ter um foo.await!() não é difícil de ler, na minha opinião, ESPECIALMENTE com realce de sintaxe adequado, que não deve ser ignorado.

Não entendeu o significado disso? O que faz é essencialmente o seguinte (ignore o tipo mystakes):

trait Future {
    fn await!(self) -> Self::Item {
        await self
    }
}

AKA await this_foo e this_foo.await!() são exatamente iguais. O que é fácil de entender mal sobre isso?

E no tópico de novos usuários: novos usuários para quê? Programação em geral ou novos usuários Rust como linguagem, mas com experiência em linguagem de programação? Porque se for o primeiro, então eu duvido que eles se interessem por programação assíncrona imediatamente. E se for o último, então é mais fácil explicar a semântica do postfix await (como explicado acima) sem confusão.

Alternativamente, se apenas o prefixo await for adicionado, nada que eu saiba interrompe a criação de um programa que recebe como entrada o código Rust da forma

foo.bar().baz().quux().await!().melo().await!()

e o transforma em

await (await foo.bar().baz().quux()).melo()

@ivandardi

.await!() é bom para alguns casos, e provavelmente funcionaria junto com await!(...) como:

macro_rules! await {
    // prefix
    ($fut:expr) => {...}

    // postfix
    ($self:Self) => { await!($self) }
}

No entanto, macros de método postfix não existem agora e podem nunca existir.

Se acharmos que é uma possibilidade no futuro, devemos ir com a macro await!(...) por enquanto e simplesmente adicionar o postfix no futuro, quando isso for implementado.

Ter as duas macros seria o ideal, mas se não houver intenção de implementar macros pós-fixadas no futuro, a palavra-chave de prefixo await é provavelmente a melhor aposta.

@novacrazy Posso concordar com isso e é minha proposta original. Devemos adicionar await!() por enquanto e descobrir uma forma de postfix conforme avançamos. Potencialmente, também discuta a possibilidade de macros postfix também, e se pudéssemos ad-hoc um postfix .await!() no idioma antes de ter suporte total a macro postfix no idioma. Mais ou menos como o que aconteceu com ? e o traço Try : ele foi adicionado primeiro como um caso especial e depois foi expandido para um caso mais geral. A única coisa que precisamos ter cuidado ao decidir é como seria a sintaxe geral da macro pós-fixada, que pode merecer uma discussão separada.

A palavra-chave de prefixo await ou a macro de prefixo await parecem ser a maneira mais aceitável de fazer isso, o que faz sentido, já que muitas outras linguagens fazem dessa forma.

É obviamente _executável_, mas só me lembro de dois argumentos para isso, e não os considero convincentes:

• É assim que outras línguas fazem
  
  
  
  • Isso é bom, mas já estamos fazendo as coisas de forma diferente, como não funcionar a menos que poll ed em vez de correr até o primeiro- await , porque a ferrugem é fundamentalmente diferente língua
  
  
• As pessoas gostam de ver await no início da linha
  
  
  
  • Mas nem sempre está lá, então, se esse for o único lugar para se olhar, terá problemas
  
  
  • É tão fácil ver os await s em foo(aFuture.await, bFuture.await) como se fossem prefixos
  
  
  • Na ferrugem, um já está escaneando o _end_ da linha para ? se você estiver olhando para o fluxo de controle
  
  

Perdi algo?

Se o debate fosse "meh, eles são todos iguais", eu concordaria absolutamente com "bem, se realmente não nos importamos, podemos também fazer o que todo mundo faz". Mas não acho que é onde estamos.

@scottmcm Sim para, "meh, eles são todos iguais." Pelo menos da perspectiva do usuário.

Portanto, devemos encontrar um equilíbrio decente entre legibilidade, familiaridade, facilidade de manutenção e desempenho. Portanto, minha afirmação em meu último comentário é verdadeira, com macro await!() se pretendemos adicionar macros de método postfix ( .await!() ) no futuro, ou apenas uma palavra-chave de prefixo chata await caso contrário.

Eu digo chato, porque chato é bom. Queremos manter nossa mente longe da sintaxe em si ao escrever código com eles.

Se f.await() não for uma boa ideia, então prefiro a sintaxe de prefixo.

1. Como usuário, espero que a linguagem que uso tenha apenas algumas regras de sintaxe e, usando essas regras, posso inferir com segurança o que ela está fazendo. NÃO exceções aqui e ali. Em Rust, async está no início, await no início não será uma exceção. No entanto, f await , forma de palavra-chave post seria. f.await parece com acesso de campo, uma exceção . f.await!() tem macro postfix nunca apareceu na linguagem, e não sei para quais outros casos ela seria adequada, uma exceção . Não temos uma resposta de como essas sintaxes se tornariam regras, e não exceções únicas .

2. Quando uma exceção é feita, espero que faça sentido intuitivamente. Tome ? como exemplo, que pode ser visto como uma exceção porque não é frequente em outras línguas. f()?.map() lê quase como compute f () e este resultado é bom? O ? aqui se explica. Mas para f await eu pergunto por que é postfix ?, para f.await eu pergunto se é await um campo, f.await!() eu pergunto por que a macro aparece nessa posição? Eles não fornecem um sentido convincente / intuitivo para mim, pelo menos à primeira vista.

3. Estendendo o primeiro ponto, Rust gostaria muito de ser uma linguagem de sistemas. Os principais jogadores aqui, C / C ++ / Go / Java são todos imperativos. Também acredito que a maioria dos caras começa sua carreira com uma linguagem imperativa, C / Python / Java, não Haskell, etc. Acho que, para persuadir os desenvolvedores de sistemas e desenvolvedores de próxima geração a adotar o Rust, o Rust deve primeiro se sair bem no estilo imperativo e depois funcional, não sendo altamente funcional, mas não tem um sentimento imperativo familiar.

4. Acho que não há nada de errado em dividir uma cadeia e escrevê-la em várias linhas. Não será prolixo. É apenas explícito .

Ao ver como a discussão se move continuamente de uma direção para outra (prefixo vs pós-fixo), desenvolvi uma opinião forte de que há algo errado com a palavra-chave await e devemos nos afastar completamente dela. Em vez disso, proponho a seguinte sintaxe que acho que será um bom compromisso entre todas as opiniões que foram publicadas no tópico atual:

// syntax below is exactly the same as with prefix `await`
let response = go client.get("https://my_api").send();
let body: MyResponse = go response.into_json();

Na primeira etapa, nós o implementaríamos como um operador de prefixo regular, sem nenhum erro ao lidar com superestruturas específicas:

// code below don't compiles because `?` takes precedence over `go`
let response = go client.get("https://my_api").send()?;
let body: MyResponse = go response.into_json()?;

Na segunda etapa, implementaríamos a sintaxe do operador de prefixo diferido que também permitiria o tratamento de erros adequado.

// now `go` takes precedence over `?` if present
let response = client.get("https://my_api").go send()?;
let body: MyResponse = response.go into_json()?;

Isso é tudo.

Agora vamos ver alguns exemplos extras que fornecem mais contexto:

// A
if db.go is_trusted_identity(recipient.clone(), message.key.clone())? {
    info!("recipient: {}", recipient);
}

// B
match db.go load(message.key)? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .go send()?
    .error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .go send()?
    .error_for_status()?
    .go json()?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .go send()?
    .error_for_status()?
    .go json()?;

// F
async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.go request(url, Method::GET, None, true)?
        .res.go json::<UserResponse>()?
        .user
        .into();

    Ok(user)
}

// G
async fn log_service(&self) -> T {
   let service = self.myService.foo();
   go self.logger.log("beginning service call");
   let output = go service.exec();
   go self.logger.log("foo executed with result {}.", output));
   output
}

// H
async fn try_log(message: String) -> Result<usize, Error> {
    let logger = go acquire_lock();
    let length = logger.go log_into(message)?;
    go logger.timestamp();
    Ok(length)
}

// I
async fn await_chain() -> Result<usize, Error> {
    go (go partial_computation()).unwrap_or_else(or_recover);
}

/// J
let res = client.get("https://my_api").go send()?.go json()?;

// A
if db.as is_trusted_identity(recipient.clone(), message.key.clone())? {
    info!("recipient: {}", recipient);
}

// B
match db.as load(message.key)? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .as send()?
    .error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .as send()?
    .error_for_status()?
    .as json()?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .as send()?
    .error_for_status()?
    .as json()?;

// F
async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.as request(url, Method::GET, None, true)?
        .res.as json::<UserResponse>()?
        .user
        .into();

    Ok(user)
}

// G
async fn log_service(&self) -> T {
   let service = self.myService.foo();
   as self.logger.log("beginning service call");
   let output = as service.exec();
   as self.logger.log("foo executed with result {}.", output));
   output
}

// H
async fn try_log(message: String) -> Result<usize, Error> {
    let logger = as acquire_lock();
    let length = logger.as log_into(message)?;
    as logger.timestamp();
    Ok(length)
}

// I
async fn await_chain() -> Result<usize, Error> {
    as (as partial_computation()).unwrap_or_else(or_recover);
}

/// J
let res = client.get("https://my_api").as send()?.as json()?;

IMO, esta sintaxe é melhor do que alternativas em todos os aspectos:

✓ Consistência: parece muito orgânico dentro do código Rust e não requer quebra de estilo de código
✓ Composibilidade: integra-se bem com outros recursos do Rust, como encadeamento e tratamento de erros
✓ Simplicidade: é curto, descritivo, fácil de entender e fácil de trabalhar
✓ Reutilização: a sintaxe do operador de prefixo diferido também seria útil em outros contextos
✓ Documentação: implica que os despachos do lado da chamada fluem em algum lugar e espera até que ele retorne
✓ Familiaridade: fornece um padrão já familiar, mas faz isso com menos vantagens e desvantagens
✓ Legibilidade: é lido como um inglês simples e não distorce o significado das palavras
✓ Visibilidade: sua posição torna muito difícil ser disfarçado em algum lugar do código
✓ Acessibilidade: pode ser facilmente pesquisado no Google
✓ Bem testado: o golang é popular hoje em dia com uma sintaxe de aparência semelhante
✓ Surpresas: é difícil não entender bem como abusar dessa sintaxe
✓ Gratificação: após um pequeno aprendizado, cada usuário ficará satisfeito com o resultado

Edit: como @ivandardi apontou no comentário abaixo, alguns pontos devem ser esclarecidos:

1. Sim, essa sintaxe é um pouco difícil de analisar, mas ao mesmo tempo é impossível inventar uma sintaxe aqui que não tivesse problemas de legibilidade. go sintaxe para mim parece ser menos maléfica aqui, já que na posição do prefixo é exatamente a mesma que com o prefixo await , e na posição deferida é IMO mais legível do que o pós-fixado await por exemplo:

match db.go load(message.key) await {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

onde não await parece ambíguo e tem uma associatividade diferente de todas as palavras-chave existentes, mas também pode se tornar um bloqueador se decidirmos implementar blocos de await em algum momento no futuro.

2. Exigirá a criação de RFC, implementação e estabilização da sintaxe do "operador de prefixo adiado". Essa sintaxe não seria específica para código assíncrono, no entanto, usá-lo em assíncrono seria a principal motivação para isso.

3. Na sintaxe do "operador de prefixo adiado", a palavra-chave é importante porque:

• a palavra-chave longa aumentaria o espaço entre a variável e o método, o que é ruim para a legibilidade
• palavra-chave longa é escolha estranha para operador de prefixo
• a palavra-chave longa é desnecessariamente detalhada quando queremos que o código assíncrono pareça sincronizado

De qualquer forma, é bem possível começar a usar await vez de go e renomeá-lo na edição de 2022. Naquela época, é muito provável que uma palavra-chave ou operador diferente seja inventado. E podemos até decidir que nenhuma renomeação é necessária. Descobri que await pode ser lido.

// A
if db.await is_trusted_identity(recipient.clone(), message.key.clone())? {
    info!("recipient: {}", recipient);
}

// B
match db.await load(message.key)? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .await send()?
    .error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .await send()?
    .error_for_status()?
    .await json()?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .await send()?
    .error_for_status()?
    .await json()?;

// F
async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.await request(url, Method::GET, None, true)?
        .res.await json::<UserResponse>()?
        .user
        .into();

    Ok(user)
}

// G
async fn log_service(&self) -> T {
   let service = self.myService.foo();
   await self.logger.log("beginning service call");
   let output = await service.exec();
   await self.logger.log("foo executed with result {}.", output));
   output
}

// H
async fn try_log(message: String) -> Result<usize, Error> {
    let logger = await acquire_lock();
    let length = logger.await log_into(message)?;
    await logger.timestamp();
    Ok(length)
}

// I
async fn await_chain() -> Result<usize, Error> {
    await (as partial_computation()).unwrap_or_else(or_recover);
}

/// J
let res = client.get("https://my_api").await send()?.await json()?;

Se você está aqui para votar negativamente, certifique-se de:

• que você entendeu corretamente, uma vez que posso não ser o melhor orador para explicar coisas novas
• que sua opinião não é tendenciosa, sine, há muitos preconceitos de onde essa sintaxe se origina
• que você colocará um motivo válido abaixo, uma vez que votos negativos silenciosos são extremamente tóxicos
• que sua razão não é sobre sentimentos imediatos, já que tentei projetar um recurso de longo prazo aqui

@ I60R

Eu tenho algumas queixas com isso.

match db.go load(message.key)? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

Isso é um pouco difícil de analisar. À primeira vista, você pensaria que estaríamos combinando db.go , mas então há algo mais nisso e você diz "oooh, ok, carregar é um método de db". IMO, essa sintaxe basicamente não funcionará porque os métodos devem sempre estar próximos ao objeto ao qual pertencem, sem espaço e interrupção de palavra-chave entre eles.

Em segundo lugar, sua proposta requer definir o que é "sintaxe de operador de prefixo diferido" e, possivelmente, generalizá-la na linguagem primeiro. Caso contrário, será algo usado apenas para código assíncrono, e estamos de volta à discussão de "por que não corrigir macros?" também.

Em terceiro lugar, não acho que a palavra-chave tenha importância alguma. No entanto, devemos favorecer await porque a palavra-chave foi reservada para a edição de 2018, enquanto a palavra-chave go não foi e deve passar por uma pesquisa crates.io mais profunda antes de ser proposta.

Ao ver como a discussão se move continuamente de uma direção para outra (prefixo vs pós-fixo), desenvolvi uma forte opinião de que há algo errado com a palavra-chave await e devemos fugir completamente dela.

Poderíamos ter (semi-) esperar implícito e tudo ficaria bem, mas vai ser difícil de vender na comunidade Rust, mesmo apesar do fato de que todo o objetivo das funções assíncronas é ocultar os detalhes de implementação e torná-los justos como bloquear io um.

@dpc Quer dizer, a melhor maneira que posso pensar sobre isso funciona como um meio-termo entre espera semi-implícita e o desejo de ter seções de código explicitamente aguardadas é algo semelhante a unsafe .

let mut res: Response = await { client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .send()?
    .error_for_status()?
    .json()?
};

Onde tudo dentro do bloco await seria automaticamente aguardado. Isso resolve a necessidade de postfix await para encadeamento, já que você pode simplesmente aguardar a cadeia inteira. Mas, ao mesmo tempo, não tenho certeza se essa forma seria desejável. Talvez outra pessoa possa encontrar um bom motivo contra isso.

@dpc O objetivo das funções assíncronas não é ocultar os detalhes, mas torná-los mais acessíveis e fáceis de usar. Nunca devemos ocultar operações potencialmente caras e devemos aproveitar as vantagens de futuros explícitos sempre que possível.

Ninguém confunde funções assíncronas com síncronas, em qualquer idioma. É puramente para organizar sequências de operações de uma forma mais legível e sustentável, em vez de escrever uma máquina de estado à mão.

Além disso, esperas implícitas, conforme mostrado no exemplo de Future , que, como já mostrei, ainda são incrivelmente poderosos. Não podemos simplesmente pegar qualquer Future e esperar por ele, isso seria altamente ineficiente.

Explícito, familiar, legível, sustentável e com desempenho: palavra-chave de prefixo await ou macro await!() , com macro potencialmente pós-fixada .await!() no futuro.

@novacrazy Mesmo que a sintaxe ideal fosse escolhida, eu ainda gostaria de usar futuros e combinadores personalizados em algumas situações. A ideia de que aqueles poderiam ser descontinuados me faz questionar toda a direção de Rust.

Claro que você pode continuar a usar combinadores, nada está sendo preterido.

É a mesma situação que ? : o novo código normalmente usará ? (porque é melhor que os combinadores), mas os combinadores Opção / Resultado ainda podem ser usados ​​(e os mais funk como or_else ainda são usados ​​regularmente).

Em particular, async / await pode substituir completamente map e and_then , mas os combinadores Future mais funk podem (e serão) usados.

Os exemplos que você dá ainda parecem terríveis em comparação com os combinadores,

Acho que não, acho que eles são muito mais claros, porque usam recursos padrão do Rust.

A clareza raramente se refere ao número de caracteres, mas tem tudo a ver com conceitos mentais.

Com o postfix await parece ainda melhor:

some_op().await?
    .another_op().await?
    .final_op().await

Você pode comparar isso ao seu original:

some_op()
    .and_then(|v| v.another_op())
    .and_then(|v2| v2.final_op())

e com a sobrecarga do gerador provavelmente será um pouco mais lento e produzirá mais código de máquina.

Por que você afirma que haverá sobrecarga extra de assíncrono / espera? Os geradores e async / await são projetados especificamente para ter custo zero e serem altamente otimizados.

Em particular, async / await compila em uma máquina de estado altamente otimizada, da mesma forma que os combinadores Future.

em vez de criar essas máquinas geradoras de estado espaguete sob o capô.

Os combinadores do Future também criam uma "máquina de estado espaguete" sob o capô, que é exatamente para o que foram projetados.

Eles não são fundamentalmente diferentes de async / await.

[Futuros combinadores] têm o potencial de compilar para um código mais eficiente.

Por favor, pare de espalhar desinformação. Em particular, async / await tem a possibilidade de ser mais rápido do que os combinadores Future.

Se descobrir que os usuários não estão satisfeitos com uma palavra-chave de prefixo, ela pode ser alterada em uma edição 2019/2020.

Como outros já disseram, as edições não são algo arbitrário que simplesmente fazemos sempre que temos vontade, elas são projetadas especificamente para acontecer apenas a cada poucos anos (no mínimo).

E como @Centril apontou, criar uma sintaxe incorreta apenas para substituí-la mais tarde é uma maneira muito ineficiente de fazer as coisas.

O ritmo da discussão está bastante alto agora; então, em um esforço para desacelerar as coisas e permitir que as pessoas acompanhem, bloqueei o problema temporariamente . Ele será desbloqueado em um dia. Nesse momento, tente ser o mais construtivo possível no futuro.

Desbloqueando o problema um dia depois ... Considere não fazer comentários já feitos e mantenha os comentários sobre o tópico (por exemplo, este não é o lugar para considerar espera implícita ou outras coisas fora do escopo ..).

Como este tem sido um longo tópico, vamos destacar alguns dos comentários mais interessantes enterrados nele.

@mehcode nos forneceu um código extenso do mundo real com await nas posições de prefixo e postfix: https://github.com/rust-lang/rust/issues/57640#issuecomment -455846086

@Centril argumentou de forma persuasiva que estabilizar await!(expr) equivale a conscientemente adicionar dívida técnica: https://github.com/rust-lang/rust/issues/57640#issuecomment -455806584

@valff nos lembrou que a sintaxe da palavra-chave postfix expr await se encaixaria mais perfeitamente com a atribuição de tipo generalizada : https://github.com/rust-lang/rust/issues/57640#issuecomment -456023146

@quodlibetor destacou que o efeito sintático dos combinadores Error e Option é exclusivo do Rust e argumenta a favor da sintaxe postfix: https://github.com/rust-lang/rust/issues/57640#issuecomment -456143523

No final do dia, a equipe lang vai precisar fazer uma ligação aqui. No interesse de identificar um terreno comum que possa levar a um consenso, talvez seja útil resumir as posições declaradas dos membros da equipe lang sobre a questão-chave da sintaxe postfix:

• @Centril expressou suporte para sintaxe postfix e explorou uma série de variações neste tíquete. Particularmente, a Centril não quer estabilizar await!(expr) .

• @cramertj expressou suporte para sintaxe postfix e especificamente para a sintaxe de palavra-chave expr await postfix.

• @joshtriplett expressou suporte para sintaxe postfix e sugeriu que também deveríamos fornecer uma versão prefixada .

• @scottmcm expressou suporte para sintaxe postfix.

• @withoutboats não quer estabilizar uma sintaxe macro. Embora preocupado em exaurir nosso "orçamento de falta de familiaridade", sem barcos considera a sintaxe da palavra-chave do postfix expr await tendo "um tiro real".

• @aturon , @eddyb , @nikomatsakis e @pnkfelix ainda não expressaram qualquer posição em relação à sintaxe nas edições # 57640 ou # 50547.

Então, o que precisamos para descobrir uma resposta sim / não para:

• Devemos ter sintaxe de prefixo?
• Devemos ter sintaxe postfix?
• Devemos ter a sintaxe de prefixo agora e descobrir a sintaxe de pós-fixada mais tarde?

Se formos com a sintaxe de prefixo, há dois concorrentes principais que acho que as pessoas aceitam mais: Útil e Óbvio, como visto neste comentário . Os argumentos contra await!() são muito fortes, então estou considerando isso descartado. Portanto, precisamos descobrir se queremos sintaxe útil ou óbvia. Em minha opinião, devemos escolher qualquer sintaxe que use menos parênteses em geral.

E quanto à sintaxe pós-fixada, isso é mais complicado. Existem também argumentos fortes para a palavra-chave pós-fixada await com espaço. Mas isso depende muito de como o código é formatado. Se o código estiver mal formatado, a palavra-chave postfix await com espaço pode parecer muito ruim. Portanto, primeiro, precisaríamos presumir que todo o código Rust será formatado corretamente com rustfmt e que rustfmt sempre dividirá as esperas encadeadas em linhas diferentes, mesmo se caberem em uma única linha. Se pudermos fazer isso, então essa sintaxe está muito boa, pois resolve o problema de legibilidade e confusão com espaços no meio de uma cadeia de uma linha.

E, finalmente, se formos com prefixo e pós-fixados, precisamos descobrir e escrever a semântica de ambas as sintaxes para ver como elas interagem entre si e como uma seria convertida na outra. Deve ser possível fazê-lo, já que a escolha entre postfix ou prefix await não deve alterar a forma como o código é executado.

Para esclarecer meu processo de pensamento, e como eu abordo e avalio as propostas de sintaxe de superfície escritas. await ,
aqui estão os objetivos que tenho (sem nenhuma ordem de importância):

1. await deve permanecer uma palavra-chave para permitir o futuro design de linguagem.
2. A sintaxe deve parecer de primeira classe.
3. O Awaiting deve ser encadeado para compor bem com ? e métodos em geral, uma vez que são predominantes no Rust. Não se deve ser forçado a fazer ligações let temporárias, que podem não ser subdivisões significativas.
4. Deve ser fácil grep para aguardar pontos.
5. Deve ser possível ver os pontos de espera de relance.
6. A precedência da sintaxe deve ser intuitiva.
7. A sintaxe deve combinar bem com IDEs e memória muscular.
8. A sintaxe deve ser fácil de aprender.
9. A sintaxe deve ser ergonômica para escrever.

Tendo definido (e provavelmente esquecido ...) alguns dos meus objetivos, aqui está um resumo e minha avaliação de algumas propostas a respeito deles:

1. Manter await como uma palavra-chave torna difícil usar uma sintaxe baseada em macro, seja await!(expr) ou expr.await!() . Para usar uma sintaxe de macro, await como macro fica codificado e não integrado com a resolução de nome (ou seja, use core::await as foo; torna-se impossível) ou await é abandonado como uma palavra-chave inteiramente.

2. Eu acredito que as macros têm um sentimento distinto de não ser de primeira classe sobre elas, uma vez que são destinadas a inventar sintaxe no espaço do usuário. Embora não seja um ponto técnico, o uso da sintaxe macro em uma construção central da linguagem dá uma impressão pouco polida. Indiscutivelmente, as sintaxes .await e .await() também não são as sintaxes de primeira classe; mas não tão de segunda classe quanto as macros pareceriam.

3. O desejo de facilitar o encadeamento faz com que qualquer sintaxe de prefixo funcione mal, enquanto as sintaxes pós-fixadas naturalmente compõem com cadeias de métodos e ? em particular.

4. O grepping é mais fácil quando a palavra-chave await é usada, seja ela pós-fixada, prefixo, macro, etc. Quando uma sintaxe baseada em sigilo é usada, por exemplo, # , @ , ~ , o grep torna-se mais difícil. A diferença não é grande, mas .await é ligeiramente mais fácil de fazer grep do que await e await já que qualquer um deles pode ser incluído como palavras nos comentários, enquanto é mais improvável para .await .

5. Sigilos são provavelmente mais difíceis de detectar de relance, enquanto await é mais fácil de ver e especialmente a sintaxe destacada. Foi sugerido que .await ou outras sintaxes de postfix são mais difíceis de detectar de relance ou que o postfix await oferece baixa legibilidade. No entanto, na minha opinião, @scottmcm corretamente observa que os resultados futuros são comuns e que .await? ajuda a chamar atenção extra para si mesmo. Além disso, Scott observa que o prefixo await leva a sentenças de caminho de jardim e que o prefixo esperar no meio das expressões não é mais legível do que o pós-fixo. Com o advento do operador ? , os programadores do Rust já precisam verificar o final das linhas para procurar o fluxo de controle .

6. A precedência de .await e .await() são notáveis ​​por serem completamente previsíveis; eles funcionam como suas contrapartes de acesso de campo e chamada de método. Uma macro pós-fixada provavelmente teria a mesma precedência que uma chamada de método. Enquanto isso, o prefixo await tem uma precedência consistente, previsível e não útil em relação a ? (ou seja, await (expr?) ), ou a precedência é inconsistente e útil (ou seja, (await expr)? ). Um sigilo pode receber a precedência desejada (por exemplo, tomando sua intuição de ? ).

7. Em 2012, @nikomatsakis notou que Simon Peyton Jones notou uma vez (p. 56) que ele tem inveja do "poder do ponto" e como ele fornece magia IDE, por meio da qual você pode restringir a função ou campo que você quer dizer. Como o poder do ponto existe em muitas linguagens populares (por exemplo, Java, C #, C ++, ..), isso fez com que "alcançar o ponto" fosse enraizado na memória muscular. Para ilustrar o quão poderoso é esse hábito, aqui está uma captura de tela, devido a @scottmcm , do Visual Studio com Re # er:
   

   C # não tem espera de postfix. No entanto, isso é tão útil que é mostrado em uma lista de preenchimento automático sem ser uma sintaxe válida. No entanto, pode não ocorrer a muitos, inclusive a mim, tentar .aw quando .await não é a sintaxe de superfície. Considere o benefício para a experiência IDE, se fosse. As sintaxes await expr e expr await não oferecem esse benefício.

8. Sigilos provavelmente ofereceriam pouca familiaridade. O prefixo await traz o benefício da familiaridade com C #, JS, etc. No entanto, eles não separam await e ? em operações distintas, enquanto o Rust o faz. Também não é um exagero ir de await expr para expr.await - a mudança não é tão radical quanto ir com um sigilo. Além disso, devido ao ponto-power mencionado acima, é provável que .await seja aprendido digitando expr. e vendo await como a primeira opção no pop-up de preenchimento automático.

9. Sigilos são fáceis de escrever e oferecem boa ergonomia. No entanto, embora .await seja mais longo para digitar, ele também vem com poderes de ponto que podem tornar o fluxo de escrita ainda melhor. Não ter que quebrar em let declarações também facilita uma melhor ergonomia. Prefixo await , ou pior ainda await!(..) , não possui poderes de pontos e habilidades de encadeamento. Ao comparar .await , .await() e .await!() , a primeira oferta é a mais concisa.

Como nenhuma sintaxe é a melhor para atingir todos os objetivos simultaneamente, deve-se fazer uma troca. Para mim, a sintaxe com mais benefícios e menos desvantagens é .await . Notavelmente, ele pode ser encadeado, preserva await como uma palavra-chave, é greppable, tem poderes de ponto e, portanto, pode ser aprendido e ergonômico, tem precedência óbvia e, finalmente, é legível (especialmente com boa formatação e destaque).

@Centril Só para esclarecer algumas dúvidas. Em primeiro lugar, gostaria de confirmar que você deseja apenas aguardar o postfix, certo? Em segundo lugar, como abordar a dualidade de .await sendo um acesso de campo? Estaria ok ter .await como ele, ou .await() com o parêntese ser favorecido de forma a implicar que algum tipo de operação está acontecendo lá? E em terceiro lugar, com a sintaxe .await , seria esperar ser a palavra-chave ou apenas um identificador de "acesso ao campo"?

Em primeiro lugar, gostaria de confirmar que você deseja apenas aguardar o postfix, certo?

Sim. Agora, pelo menos.

Em segundo lugar, como abordar a dualidade de .await sendo um acesso de campo?

É uma pequena desvantagem; há uma grande vantagem no poder do ponto. A distinção é algo que acredito que os usuários aprenderão rapidamente, especialmente porque é uma palavra-chave destacada e a construção será usada com frequência. Além disso, como Scott observou, .await? será o mais comum, o que deve aliviar ainda mais a situação. Também deve ser fácil adicionar uma nova entrada de palavra-chave para await em rustdoc, da mesma forma que fizemos para, digamos, fn .

Estaria ok ter .await como ele, ou .await() com o parêntese ser favorecido de forma a implicar que algum tipo de operação está acontecendo lá?

Eu prefiro .await sem cauda () ; ter () no final parece um sal desnecessário na maioria dos casos e, imagino, deixaria os usuários mais inclinados a procurar o método.

E em terceiro lugar, com a sintaxe .await , seria esperar ser a palavra-chave ou apenas um identificador de "acesso ao campo"?

await permaneceria uma palavra-chave. Presumivelmente, você alteraria a libsyntax de forma a não errar ao encontrar await após . e, em seguida, representaria de forma diferente em AST ou ao reduzir para HIR ... mas isso é principalmente um detalhe de implementação .

Obrigado por esclarecer tudo isso! 👍

Neste ponto, a questão principal parece ser se devemos seguir uma sintaxe pós-fixada. Se essa for a direção, então certamente podemos definir qual. Lendo a sala, a maioria dos defensores da sintaxe pós-fixada aceitaria qualquer sintaxe pós-fixada razoável sobre a sintaxe de prefixo.

Entrando neste tópico, a sintaxe pós-fixada parecia estar em desvantagem. No entanto, atraiu o apoio claro de quatro membros da equipe lang e a abertura de um quinto (os outros quatro permaneceram em silêncio até agora). Além disso, atraiu um apoio considerável da comunidade mais ampla que comentou aqui.

Além disso, os defensores da sintaxe postfix parecem ter uma clara convicção de que é o melhor caminho para o Rust. Parece que algum problema profundo ou refutações convincentes aos argumentos até agora apresentados seriam necessários para voltar atrás.

Diante disso, parece que precisamos ouvir @withoutboats , que certamente tem seguido esse tópico de perto, e dos outros quatro membros da equipe lang. As opiniões deles provavelmente irão impulsionar este tópico. Se eles tiverem preocupações, discuti-las seria a prioridade. Se eles estiverem convencidos do caso da sintaxe pós-fixada, então podemos prosseguir para encontrar um consenso para qual.

Opa, acabei de notar que o @Centril já comentou, então irei esconder meu post para limpeza.

@ivandardi Dado o objetivo (1) do post, meu entendimento é que await ainda seria uma palavra-chave, então nunca seria um acesso de campo, da mesma forma que loop {} nunca é uma expressão literal de struct. E eu esperava que fosse destacado para tornar o mais óbvio (como https://github.com/rust-lang/rust-enhanced/issues/333 está esperando para fazer no Sublime).

Minha única preocupação é que fazer a sintaxe de await parecer um acesso diferente pode causar confusão em uma base de código da edição 2015 sem perceber. (2015 é o padrão quando não especificado, abrindo o projeto de outra pessoa, etc.) Contanto que a edição de 2015 tenha um erro claro quando não há um campo await (e aviso se houver), eu acho isso (junto com o argumento maravilhoso de Centril) elimina minhas preocupações pessoais sobre um campo de palavra-chave (ou método).

Ah, e uma coisa que também devemos decidir enquanto estamos nisso é como rustfmt acabaria formatando-o.

let val = await future;
let val = await returns_future();
let res = client.get("https://my_api").await send()?.await json()?;

1. Usa await - cheque
2. Primeira classe - verificar
3. Encadeamento - verificar
4. Grepping - verificar
5. Sem sigilo - verificar
6. Precedência - ¹check
7. Potência do ponto - ²check
8. Fácil de aprender - ³check
9. Ergonômico - verificar

¹Precedência: espaço após await torna não óbvio na posição diferida. No entanto, é exatamente o mesmo que no código a seguir: client.get("https://my_api").await_send()?.await_json()? . Para todos os falantes de inglês é ainda mais natural do que com todas as outras propostas

²Pot power: exigiria suporte adicional para IDE mover await para a esquerda da chamada do método após . , ? ou ; ser digitado em seguida. Não parece ser muito difícil de implementar

³Fácil de aprender: na posição de prefixo já é familiar para programadores. Na posição adiada , seria óbvio depois que a sintaxe fosse estabilizada

Mas o ponto mais forte dessa sintaxe é que ela será muito consistente:

• Não pode ser confundido com acesso à propriedade
• Tem precedência óbvia com ?
• Sempre terá a mesma formatação
• Corresponde à linguagem humana
• Não afeta a ocorrência horizontal variável na cadeia de chamada de método *

Com a variante pós-fixada é difícil prever qual função é async e onde estaria a próxima ocorrência de await no eixo horizontal:

let res = client.get("https://my_api")
    .very_long_method_name(param, param, param).await?
    .short().await?;

Com a variante adiada, seria quase sempre o mesmo:

let res = client.get("https://my_api")
    .await very_long_method_name(param, param, param)?
    .await short()?;

Não haveria um. entre o await e a próxima chamada de método? Gostar
get().await?.json() .

Na quarta-feira, 23 de janeiro de 2019, 05:06 I60R < [email protected] escreveu:

deixe val = aguardar futuro;
let res = client.get ("https: // my_api") .await send () ?. await json () ?;

1. Usos aguardam - verificar
2. Primeira classe - verificar
3. Encadeamento - verificar
4. Grepping - verificar
5. Sem sigilo - verificar
6. Precedência - ¹check
7. Potência do ponto - ²check
8. Fácil de aprender - ³check
9. Ergonômico - verificar

---

¹Precedência: o espaço torna não óbvio na posição diferida. No entanto é
exatamente o mesmo que no código a seguir: client.get ("https: // my_api
") .await_send () ?. await_json () ?. Para todos os falantes de inglês é ainda mais
natural do que com todas as outras propostas

² Potência do ponto: seria necessário suporte adicional para o IDE mover e aguardar para
à esquerda da chamada de método depois. ou? é digitado a seguir. Não parece ser também
difícil de implementar

³Fácil de aprender: na posição de prefixo já é familiar para programadores,
e na posição defendida , seria óbvio depois que a sintaxe fosse

estabilizado

Mas o ponto mais forte sobre essa sintaxe é que ela será muito
consistente:

• Não pode ser confundido com acesso à propriedade
• Ele tem precedência óbvia com?
• Sempre terá a mesma formatação
• Corresponde à linguagem humana
• Não é afetado pela ocorrência horizontal variável na chamada do método
  cadeia*

* a explicação está escondida sob spoiler

Com a variante postfix, é difícil prever qual função é assíncrona e
onde seria a próxima ocorrência de await no eixo horizontal:

deixe res = client.get ("https: // my_api")

.very_long_method_name(param, param, param).await?

.short().await?;

Com a variante adiada, seria quase sempre o mesmo:

deixe res = client.get ("https: // my_api")

.await very_long_method_name(param, param, param)?

.await short()?;

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/rust-lang/rust/issues/57640#issuecomment-456693759 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AIA8Ogyjc8LW6teZnXyzOCo31-0GPohTks5vGAoDgaJpZM4aBlba
.

também devemos decidir enquanto estamos nisso é como rustfmt acabaria formatando-o

Esse é o domínio de https://github.com/rust-dev-tools/fmt-rfcs , então eu diria que está fora do tópico para este assunto. Tenho certeza de que haverá algo consistente com qualquer correção e precedência escolhida.

@ I60R

let res = client.get("https://my_api").await send()?.await json()?;

Como isso procuraria funções de funções livres? Se estou lendo direito, na verdade é um prefixo await .

Acho que isso mostra que não devemos ser tão rápidos em desacreditar a experiência da equipe da linguagem C #. A Microsoft se preocupa muito com os estudos de usabilidade e estamos tomando uma decisão com base em uma única linha de código e na premissa de que Rust é especial o suficiente para ter uma sintaxe diferente de todas as outras linguagens. Não concordo com essa premissa - mencionei o LINQ acima e os métodos de extensão que estão difundidos no C #.

No entanto, pode não ocorrer a muitos, inclusive a mim, tentar .aw quando .await não é a sintaxe de superfície.

~ Não acho que isso ocorrerá a alguém familiarizado com os outros idiomas. ~ Tirando isso, você esperaria que o pop-up de conclusão incluísse os métodos await e Future ?

[...] e estamos tomando uma decisão aqui com base em uma única linha de código e na premissa de que Rust é especial o suficiente para ter uma sintaxe diferente de todas as outras linguagens. Eu discordo dessa premissa [...]

@lnicola , só quero destacar, caso você e outras pessoas tenham perdido (é fácil perder no dilúvio de comentários): https://github.com/rust-lang/rust/issues/57640#issuecomment -455846086

Vários exemplos reais do código de produção real.

Dado o comentário de @Centril acima , parece que as opções de postfix em contenção mais forte são expr await sintaxe de palavra-chave postfix e expr.await sintaxe de campo postfix (e talvez a sintaxe de método postfix ainda não tenha sido lançada).

Comparado com a palavra-chave postfix, @Centril argumenta que o campo postfix se beneficia do "poder do ponto" - que os IDEs podem ser mais capazes de sugeri-lo como um preenchimento automático - e que instâncias de seu uso podem ser mais fáceis de encontrar com grep porque o ponto inicial fornece desambiguação do uso da palavra nos comentários.

Por outro lado, @cramertj argumentou a favor da sintaxe de palavra-chave postfix com base em que tal sintaxe deixa claro que não é uma chamada de método ou acesso a campo. @withoutboats argumentou que a palavra-chave postfix é a mais familiar das opções do postfix.

Com relação ao "poder do ponto", devemos considerar que um IDE ainda pode oferecer await como conclusão após um ponto e simplesmente remover o ponto quando a conclusão for selecionada. Um IDE suficientemente inteligente (por exemplo, com RLS) poderia até perceber o futuro e oferecer await após um espaço.

As opções de campo e método postfix parecem oferecer a maior área de superfície para objeções, devido à ambigüidade, em comparação com a palavra-chave postfix. Como parte do suporte para campo / método postfix sobre palavra-chave postfix parece vir de um leve desconforto com a presença do espaço no encadeamento de métodos, devemos revisar e nos envolver com a observação de @valff de que a palavra-chave postfix ( foo.bar() await ) não parecerá mais surpreendente do que a atribuição generalizada de tipo ( foo.bar() : Result<Vec<_>, _> ). Para ambos, o encadeamento continua após esse interlúdio separado por espaço.

@ivandardi , @lnicola ,

Eu atualizei meu comentário recente com o exemplo ausente para chamada de função gratuita. Se você quiser mais exemplos, pode consultar o último spoiler em meu comentário anterior

No interesse de debater future.await? vs. future await? ...

Algo que não é muito discutido é o agrupamento visual ou grep de uma cadeia de métodos.

considere ( match vez de await para realce de sintaxe)

post(url).multipart(form).send().match?.error_for_status()?.json().match?

em comparação com

post(url).multipart(form).send() match?.error_for_status()?.json() match?

Quando examino visualmente await na primeira cadeia, identifico de forma clara e rápida send().await? e vejo que estamos aguardando o resultado de send() .

No entanto, quando examino visualmente await na segunda cadeia, primeiro vejo await?.error_for_status() e preciso desligar, não, voltar e conectar send() await .

Sim, alguns desses mesmos argumentos se aplicam à atribuição de tipo generalizada, mas esse ainda não é um recurso aceito. Embora eu goste de atribuição de tipo em certo sentido, sinto que em um contexto de expressão _geral_ (vago, eu sei) ele deve ser delimitado por parênteses. No entanto, tudo isso está fora do tópico desta discussão. Também tenha em mente que a quantidade de await em uma base de código tem uma grande mudança de ser significativamente maior do que a quantidade de atribuição de tipo.

A atribuição generalizada de tipo também vincula o tipo à expressão atribuída por meio do uso de um operador distinto : . Assim como outro operador binário, sua leitura torna (visualmente) claro que as duas expressões são uma única árvore. Considerando que future await não tem operador e pode facilmente ser confundido com future_await por motivo de raramente ver dois nomes não separados por um operador, exceto se o primeiro for uma palavra-chave (exceções se aplicam, que não é para dizer que prefiro sintaxe de prefixo, não).

Compare isso com o inglês, se desejar, onde um hífen ( - ) é usado para agrupar visualmente palavras que, de outra forma, seriam facilmente interpretadas como separadas.

Acho que isso mostra que não devemos ser tão rápidos em desacreditar a experiência da equipe da linguagem C #.

Não acho que "tão rápido" e "desacreditar" sejam justos aqui. Acho que está acontecendo aqui a mesma coisa que aconteceu na própria RFC async / await: considerar cuidadosamente por que isso foi feito de uma maneira e descobrir se o equilíbrio sai da mesma maneira para nós. A equipe C # é mencionada explicitamente em um:

• 2394-async_await.md # polymorphic-return-a-non-factor-for-us
• 2394-async_await.md # hot-async-functions

Eu pensei que a ideia de await era que você realmente queria o resultado, não o futuro
então, talvez a sintaxe de await deva ser mais como a sintaxe de 'ref'

let future = task()
mas
let await result = task()

então para encadear você deve fazer

task().chained_method(|future| { /* do something with future */ })

mas

task().chained_method(|await result| { /* I've got the result */ })

- foo.await             // NOT a real field
- foo.await()           // NOT a real method
- foo.await!()          // NOT a real macro

Todos eles funcionam bem com encadeamento e todos têm contras que não são campos / métodos / macros reais.
Mas como await , como palavra-chave, já é uma coisa especial, não precisamos torná-la mais especial.
Devemos apenas selecionar o mais simples, foo.await . Ambos () e !() são redundantes aqui.

@liigo

- foo await        // IS neither field/method/macro, 
                   // and clearly seen as awaited thing. May be easily chained. 
                   // Allow you to easily spot all async spots.

@mehcode

Quando examino visualmente a primeira cadeia de await, identifico de forma clara e rápida send (). Await? e ver que estamos aguardando o resultado do send ().

Gosto mais da versão espaçada, pois é muito mais fácil ver onde o futuro se constrói e onde o espera. É muito mais fácil ver o que acontece, IMHO

Com a separação de pontos, parece muito com uma chamada de método. O destaque de código não vai ajudar muito e nem sempre está disponível.

Finalmente, acredito que o encadeamento não é o caso de uso principal (exceto para ? , mas foo await? é o mais claro possível), e com espera simples torna-se

post(url).multipart(form).send().match?

vs

post(url).multipart(form).send() match?

Onde o último parece muito mais magro.

Portanto, se tivermos reduzido para future await e future.await , podemos apenas tornar o "ponto" mágico opcional? Para que as pessoas possam escolher o que desejam e, o mais importante, parem de discutir e sigam em frente!

Não é prejudicial ter sintaxe opcional, Rust tem muitos desses exemplos. o mais conhecido é o último esperador ( ; ou , ou o que quer que seja, após o último item, como em (A,B,) ) são geralmente opcionais. Não vi uma razão forte para não tornar o ponto opcional.

Acho que seria um bom momento para apenas fazer isso em Nightly e deixar o ecossistema decidir qual é o melhor para eles. Podemos ter lints para reforçar o estilo preferido, tornando-o personalizável.

Então, antes de chegar ao Estável, revisamos o uso da comunidade e decidimos se devemos escolher um ou apenas deixar os dois.

Eu discordo totalmente da noção de que macros não seriam de primeira classe o suficiente para este recurso (eu não o consideraria um recurso central em primeiro lugar) e gostaria de realçar meu comentário anterior sobre await!() (não importa se prefixo ou pós-fixado) não ser uma "macro real", mas acho que no final muitas pessoas querem que esse recurso seja estabilizado o mais rápido possível, em vez de bloquear isso em macros pós-fixadas e prefixo esperar realmente não é um bom ajuste para Rust.

Em qualquer caso, bloquear este tópico por um dia só ajudou muito e vou cancelar a inscrição agora. Sinta-se à vontade para me mencionar se estiver respondendo diretamente a um dos meus pontos.

Meu argumento contra a sintaxe com . é que await não é um campo e, portanto, não deve se parecer com um campo. Mesmo com destaque de sintaxe e fonte em negrito, parecerá um campo de alguma forma . seguido por palavra está fortemente associado ao acesso ao campo.

Não há razão para usar a sintaxe com . para uma melhor integração IDE, já que seríamos capazes de capacitar qualquer sintaxe diferente com . completamento usando algo como o recurso de completamento postfix disponível no Intellij IDEA.

Precisamos perceber await como palavra-chave de fluxo de controle. Se decidirmos fortemente usar o postfix await , devemos considerar a variante sem . e proponho usar a seguinte formatação para enfatizar melhor os pontos de bloqueio com possível interrupção:

async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.request(url, Method::GET, None, true)
        await?.res.json::<UserResponse>()
        await?.user
        .into();
    Ok(user)
}

// A
if db.is_trusted_identity(recipient.clone(), message.key.clone()) 
    await? {
    info!("recipient: {}", recipient);
}

// B
match db.load(message.key)
    await? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .send()
    await?.error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .send()
    await?.error_for_status()?
    .json()
    await?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .send()
    await?.error_for_status()?
    .json()
    await?;

async fn request_user(self, user_id: String) -> Result<User> {
    let url = format!("users/{}/profile", user_id);
    let user = self.request(url, Method::GET, None, true)
        yield?.res.json::<UserResponse>()
        yield?.user
        .into();
    Ok(user)
}

// A
if db.is_trusted_identity(recipient.clone(), message.key.clone()) 
    yield? {
    info!("recipient: {}", recipient);
}

// B
match db.load(message.key)
    yield? {
    Some(key) => key,
    None => {
        return Err(/* [...] */);
    }
};

// C
let mut res = client.get(&script_src)
    .header("cookie", self.cookies.read().as_header_value())
    .header("user-agent", USER_AGENT)
    .send()
    yield?.error_for_status()?;

// D
let mut res: InboxResponse = client.get(inbox_url)
    .headers(inbox_headers)
    .send()
    yield?.error_for_status()?
    .json()
    yield?;

// E
let mut res: Response = client.post(url)
    .multipart(form)
    .headers(headers.clone())
    .send()
    yield?.error_for_status()?
    .json()
    yield?;

Isso também pode ser uma resposta ao ponto @ivandardi sobre formatação

Acho que todos esses exemplos de postfix await são mais contra do que a favor. Longas cadeias de espera parecem erradas e o encadeamento deve ser mantido para futuros combinadores.

Compare (com match como await para realce de sintaxe):

post(url)?.multipart(form).send()?.match?.error_for_status()?.json().match?

para

let value = await post(url)?.multipart(form).send()?.error_for_status()
                 .and_then(|resp| resp.json()) // and then parse JSON

// now handle errors

Observe a falta de espera no meio? Porque o encadeamento geralmente pode ser resolvido com um design de API melhor. Se send() retorna um futuro personalizado com métodos adicionais, digamos, para converter mensagens de status diferentes de 200 em erros de hardware, então não há necessidade de esperas extras. No momento, pelo menos em reqwest , parece funcionar no local e produzir um simples Result vez de um novo futuro, que é de onde vem o problema aqui.

O encadeamento de espera é um cheiro forte de código na minha opinião, e .await ou .await() confundirá tantos novos usuários que nem chega a ser engraçado. .await especialmente parece algo fora do Python ou PHP, onde acessos de membros variáveis ​​podem magicamente ter um comportamento especial.

await deve ser um óbvio à frente, como se dissesse: "antes de continuar, esperamos por este" não "e depois esperamos por este". O último é literalmente o combinador and_then .

Outra maneira potencial de pensar sobre isso é considerar async / await expressões e futuros como iteradores. Ambos são preguiçosos, podem ter muitos estados e podem ser encerrados com sintaxe ( for-in para iteradores, await para futuros). Não proporíamos uma extensão de sintaxe para iteradores para encadea-los como expressões regulares como estamos aqui, certo? Eles usam combinadores para encadeamento e operações assíncronas / futuros devem fazer o mesmo, terminando apenas uma vez. Funciona bem.

Por fim, e o mais importante, quero poder folhear verticalmente os primeiros recuos de uma função e ver claramente onde acontecem as operações assíncronas. Minha visão não é tão boa, e ter esperas no final da linha ou presa no meio tornaria as coisas muito mais difíceis que posso simplesmente ficar com o futuro inteiramente cru.

Todos, por favor, leiam esta postagem do blog antes de comentar.

Async / await não tem a ver com conveniência. Não é sobre como evitar combinadores.

Trata-se de habilitar coisas novas que não podem ser feitas com combinadores.

Portanto, quaisquer sugestões de "vamos usar combinadores" estão fora do assunto e devem ser discutidas em outro lugar.

Observe a falta de espera no meio? Porque o encadeamento geralmente pode ser resolvido com um design de API melhor.

Você não obterá uma cadeia bonita no exemplo assíncrono real. Exemplo real:

req.into_body().concat2().and_then(move |chunk| {
    from_slice::<Update>(chunk.as_ref())
        .into_future()
        .map_err(|_| {
            ...
        })
        .and_then(|update| {
            ...
        })
        .and_then(move |(user, file_id, chat_id, message_id)| {
            do_thing(&file_id)
                .and_then(move |file| {
                    if some_cond {
                        Either::A(do_yet_another-thing.and_then(move |bytes| {
                            ...

                            if another_cond {
                                ...
                                Either::A(
                                    do_other_thing()
                                        .then(move |res| {
                                            ...
                                        }),
                                )
                            } else {
                                Either::B(future::ok(()))
                            }
                        }))
                    } else {
                        Either::B(future::ok(()))
                    }
                })
                .map_err(|e| {
                    ...
                })
        })
        // ...and here we unify both paths
        .map(|_| {
            Response::new(Body::empty())
        })
        .or_else(Ok)
})

Os combinadores não ajudam aqui. O aninhamento pode ser removido, mas não é fácil (tentei duas vezes e falhei). Você tem toneladas de Either:A(Either:A(Either:A(...))) no final.

OTOH é facilmente resolvido com async / await .

@Pauan escreveu antes de eu terminar minha postagem. Que assim seja. Não mencione os combinadores, async/await não devem ser semelhantes. Tudo bem se isso acontecer, há coisas mais importantes a se considerar.

Votar negativamente em meu comentário não tornará os combinadores mais convenientes.

Lendo o comentário de atribuição de tipo , pensei em como isso ficaria combinado com await . Dada a reserva que algumas pessoas têm com .await ou .await() como campos de membros / métodos de acesso confusos, eu me pergunto se uma sintaxe geral de "atribuição" poderia ser uma opção, (ou seja, "dê-me o que await retorna ").

Usando yield para await para realce de sintaxe

let result = connection.fetch("url"):yield?.collect_async():yield?;

Combinado com a atribuição de tipo, por exemplo:

let result = connection.fetch("url") : yield?
    .collect_async() : yield Vec<u64>?;

Vantagens: ainda parece bom (IMHO), sintaxe diferente de acesso de campo / método.
Desvantagens: conflitos potenciais com a atribuição de tipo (?), Atribuições múltiplas teoricamente possíveis:

foo():yield:yield

Edit: Ocorreu-me que usar 2 atribuições seria mais lógico no exemplo combinado:

let result = connection.fetch("url") : yield?
    .collect_async() : yield : Vec<u64>?;

@Pauan , seria inapropriado aplicar excessivamente aquela postagem do blog. Os combinadores podem ser aplicados em conjunto com a sintaxe await para evitar os problemas que ela descreve.

O problema principal sempre foi que um futuro gerável deve ser 'static , mas se você capturou variáveis ​​por referência nesses combinadores, acabou com um futuro que não era 'static . Mas esperar um futuro diferente de 'static não torna o fn assíncrono em que você não está 'static . Então você pode fazer coisas assim:

`` `ferrugem
// fatia: & [T]

deixe x = aguardar futuro.e_então (| i | se slice.contém (i) {async_fn (slice)});

Então, eu estava planejando não comentar nada, mas queria adicionar algumas notas de alguém que não escreve muito código assíncrono, mas ainda terá que lê-lo:

• O prefixo await é muito mais fácil de notar. Isso é quando você está esperando (dentro de um async fn) ou fora (na expressão de algum corpo de macro).
• Postfix await sendo uma palavra-chave pode se destacar bem em cadeias com pouca ou nenhuma outra palavra-chave. Mas assim que você tiver fechamentos ou similares com outras estruturas de controle, seu awaits se tornará muito menos perceptível e fácil de ignorar.
• Acho .await um pseudo-campo muito estranho. Não é como qualquer outro campo em qualquer aspecto que seja importante para mim.
• Não tenho certeza se confiar na detecção de IDE e no realce de sintaxe é uma boa ideia. Há valor na facilidade de leitura quando nenhum destaque de sintaxe está disponível. Além disso, com as discussões recentes sobre como complicar a gramática e os problemas que isso causará para o conjunto de ferramentas, pode não ser uma boa ideia confiar que IDEs / editores acertam as coisas.

Eu não compartilho do sentimento de que await!() como uma macro "não parece de primeira classe". Macros são cidadãos de primeira classe em Rust. Eles também não existem apenas para "inventar sintaxe no código do usuário". Muitas macros "embutidas" não são definidas pelo usuário e não estão lá por meras razões sintáticas. format!() existe para dar ao compilador o poder de verificar estaticamente o tipo de strings de formato. include_bytes!() também não é definido pelo usuário e não está lá por meras razões sintáticas, é uma macro porque precisa ser uma extensão de sintaxe, pois, novamente, faz coisas especiais dentro do compilador e não poderia razoavelmente ser escrito de qualquer outra maneira, sem adicioná-lo como um recurso principal da linguagem.

E este é o meu ponto: macros são uma maneira perfeita de introduzir e ocultar a mágica do compilador de uma forma uniforme e nada surpreendente. Await é um bom exemplo disso: ele precisa de tratamento especial, mas sua entrada é apenas uma expressão e, como tal, é um ótimo ajuste para realização usando uma macro.

Então, eu realmente não vejo necessidade de uma palavra-chave especial. Dito isso, se vai ser uma palavra-chave, então deve ser apenas isso, uma palavra-chave simples - eu realmente não entendo a motivação de disfarçá-la como um campo. Isso simplesmente parece errado, não é um acesso de campo, nem mesmo remotamente como um acesso de campo (ao contrário, digamos, os métodos getter / setter com sugar podem ser), portanto, tratá-lo como um é inconsistente com a forma como os campos funcionam hoje na linguagem.

@ H2CO3 await! macro é bom de todas as maneiras desejáveis, exceto para duas propriedades:

1. Chaves extras são realmente irritantes quando você escreve mais um milhar de espera. A ferrugem removeu os colchetes de if/while/... blocos pelo (acredito) mesmo motivo. Pode parecer sem importância atm, mas é realmente o caso
2. Assimetria com async sendo uma palavra-chave. Async deve fazer algo maior do que apenas permitir uma macro no corpo do método. Caso contrário, poderia ser apenas um atributo #[async] no topo da função. Eu entendo que esse atributo não permitirá que você o use em blocos etc, mas fornece alguma expectativa de encontrar a palavra-chave await . Essa expectativa pode ser causada pela experiência em outras línguas, quem sabe, mas acredito fortemente que existe. Pode não ser abordado, mas deve ser considerado.

Caso contrário, poderia ser apenas um atributo #[async] no topo da função.

Por muito tempo foi, e sinto muito ver isso ir embora. Estamos introduzindo outra palavra-chave, enquanto o atributo #[async] funcionou perfeitamente bem e agora com macros procedurais semelhantes a atributos estáveis, seria até consistente com o resto da linguagem tanto sintática quanto semanticamente, mesmo se ainda fosse conhecido (e tratado especialmente) pelo compilador.

@ H2CO3 qual é o propósito ou vantagem de ter await como uma macro da perspectiva do usuário ? Existe alguma macro embutida que altera o fluxo de controle dos programas nos bastidores?

@ I60R A vantagem é a uniformidade com o resto da linguagem e, portanto, não ter que se preocupar com mais uma palavra-chave, com toda a bagagem que ela traria consigo - por exemplo, precedência e agrupamento são óbvios em uma invocação de macro.

Não vejo por que a segunda parte é relevante - não pode haver uma macro embutida que faça algo novo? Na verdade, acho que praticamente toda macro embutida faz algo "estranho" que não pode (razoavelmente / eficientemente / etc.) Ser alcançado sem o suporte do compilador. await!() não seria um novo intruso nesse aspecto.

Eu já sugeri aguardar implícito e, mais recentemente, sugerir aguardar sem cadeia .

A comunidade parece fortemente a favor da espera explícita (adoraria que isso mudasse, mas ...). No entanto, a granularidade da clareza é o que cria um padrão (ou seja, precisar dela muitas vezes na mesma expressão parece criar um padrão).

[ Aviso : a seguinte sugestão será controversa, mas dê uma chance sincera]

Estou curioso para saber se a maioria da comunidade se comprometeria e permitiria “espera implícita parcial”. Talvez ler e esperar uma vez por cadeia de expressão seja suficientemente explícito?

await response = client.get("https://my_api").send()?.json()?;

Isso é algo semelhante à desestruturação de valor, que estou chamando de desestruturação de expressão.

// Value de-structuring
let (a, b, c) = ...;

// De-sugars to:
let _abc = ...;
let a = _abc.0;
let b = _abc.1;
let c = _abc.2;

// Expression de-structuring
await response = client.get("https://my_api").send()?.json()?;

// De-sugards to:
// Using: prefix await with explicit precedence
// Since send() and json() return impl Future but ? does not expect a Future, de-structure the expression between those sub-expressions.
let response = await (client.get("https://my_api").send());
let response = await (response?.json());
let response = response?;



md5-eeacf588eb86592ac280cf8c372ef434



```rust
// If needed, given that the compiler knows these expressions creating a, b are independent,
// each of the expressions would be de-structured independently.
await (a, b) = (
    client.get("https://my_api_a").send()?.json()?,
    client.get("https://my_api_b").send()?.json()?,
);
// De-sugars to:
// Not using await syntax like the other examples since await can't currently let us do concurrent polling.
let a: impl Future = client.get("https://my_api_a").send();
let b: impl Future = client.get("https://my_api_b").send();
let (a, b) = (a.poll(), b.poll());
// return if either a or b is NotReady;

let a: impl Future = a?.json();
let b: impl Future = b?.json();
let (a, b) = (a.poll(), b.poll());
// return if either a or b is NotReady;
let (a, b) = (a?, b?);

Eu também ficaria feliz com outras implementações da ideia central, "ler, aguardar uma vez por cadeia de expressão é provavelmente suficientemente explícito". Porque reduz o clichê, mas também torna o encadeamento possível com uma sintaxe baseada em prefixo que é mais familiar para todos.

@yazaddaruvala Houve um aviso acima, então tome cuidado.

Estou curioso para saber se a maioria da comunidade se comprometeria e permitiria “espera implícita parcial”. Talvez ler e esperar uma vez por cadeia de expressão seja suficientemente explícito?

1. Não acho que a maior parte da comunidade queira algo implícito parcial. A abordagem nativa do Rust é mais como "tudo explícito". Mesmo as projeções u8 -> u32 são feitas explicitamente.
2. Não funciona bem para cenários mais complicados. O que o compilador deve fazer com Vec<Future> ?

await response = client.get("https://my_api").send()?.json()?.parse_as::<Vec<String>>()?.map(|x| client.get(x))?;

await ser executado para cada chamada aninhada? Ok, provavelmente podemos fazer o await funcionar para uma linha de código (portanto, mapFunc aninhados não serão aguardados), mas é muito fácil quebrar esse comportamento. Se await funcionar para uma linha de código, qualquer refatoração como "extrair valor" a quebra.

@yazaddaruvala

Eu entendi que você está correto em seu propósito é o prefixo esperar que tenha precedência sobre ? com a possibilidade adicional de usar esperar no lugar da palavra-chave let para alterar o contexto para polvilhar todos os futuros impl. <_ I = "7"> retorna com espera?

O que significa que essas três declarações abaixo são equivalentes:

// foo.bar() -> Result<impl Future<_>, _>>
let a = await foo.bar()?;
let a = await (foo.bar()?);
await a = foo.bar()?;

E essas duas afirmações abaixo são equivalentes:

// foo.bar() -> impl Future<Result<_, _>>
await a = foo.bar()?;
let a = await (foo.bar())?;

Não tenho certeza se a sintaxe é ideal, mas talvez ter uma palavra-chave que muda para um "contexto implícito de espera" torne os problemas da palavra-chave de prefixo menos problemáticos. E ao mesmo tempo permitindo o uso de um controle mais refinado sobre onde o await é usado quando necessário.

Em minha opinião, para prefixo de uma linha curta, aguardar tem o benefício de similaridade com muitas outras linguagens de programação e muitas linguagens humanas . Se no final for decidido que esperar deve ser apenas um sufixo, espero que às vezes acabe usando uma macro Await!() (ou qualquer forma semelhante que não entre em conflito com palavras-chave), quando sinto que estou a familiaridade profundamente arraigada com a estrutura das frases em inglês ajudará a reduzir a sobrecarga mental de ler / escrever código. Há um valor definido nas formas de sufixo para expressões mais encadeadas, mas minha visão explicitamente não baseada em fatos objetivos é que, com a complexidade humana do prefixo aguardar subsidiado pela linguagem falada, o benefício da simplicidade de ter apenas uma forma não supera claramente a clareza de código potencial de ter ambos. Supondo que você confie no programador para escolher o que for mais apropriado para o pedaço de código atual, pelo menos.

@Pzixel

Não acho que a maior parte da comunidade queira algo implícito parcial. A abordagem nativa do Rust é mais como "tudo explícito".

Eu não vejo da mesma forma. Eu vejo isso sempre sendo um compromisso entre explícito e implícito. Por exemplo:

• Tipos de variáveis ​​são necessários no escopo da função
  
  
  
  • Tipos de variáveis ​​podem estar implícitos em um escopo local.
  
  
  • Contextos de encerramento são implícitos
  
  
  • Dado que já podemos raciocinar sobre as variáveis ​​locais.
  
  
• São necessárias vidas úteis para ajudar o verificador de empréstimo.
  
  
  
  • Mas no âmbito local, eles podem ser inferidos.
  
  
  • No nível da função, os tempos de vida não precisam ser explícitos, quando todos têm o mesmo valor.
  
  
• Tenho certeza de que há mais.

Usar await apenas uma vez por expressão / instrução, com todos os benefícios do encadeamento, é um meio-termo muito razoável entre boilerplate explícito e redutor.

Não funciona bem para cenários mais complicados. O que o compilador deve fazer com Vec?

await response = client.get("https://my_api").send()?.json()?.parse_as::<Vec<String>>()?.map(|x| client.get(x))?;

Eu diria que o compilador deve errar. Há uma enorme diferença de tipo que não pode ser inferida. Enquanto isso, o exemplo com Vec<impl Future> não é resolvido por nenhuma das sintaxes neste tópico.

// Given that json() returns a Vec<imple Future>,
// do I use .await on the `Vec`? That seems odd.
// Given that the client.get() returns an `impl Future`,
// do I .await inside the .map? That wont work, given Iterator methods are not `async`
client.get("https://my_api").send().await?.json()[UNCLEAR]?.parse_as::<Vec<String>>()?.map(|x| client.get(x)[UNCLEAR])?;

Eu diria que Vec<impl Future> é um exemplo pobre, ou deveríamos manter cada sintaxe proposta no mesmo padrão. Enquanto isso, a sintaxe "parcial-implícita espera" que propus funciona melhor do que as propostas atuais para cenários mais complicados como await (a, b) = (client.get("a")?, client.get("b")?); usando postfix normal ou prefixo await let (a, b) = (client.get("a") await?, client.get("b") await?); resulta em operações de rede sequenciais, onde o parcial -versão implícita pode ser executada simultaneamente pelo compilador desugardando apropriadamente (como eu mostrei em meu post original).

Em 2011, quando o recurso async em C # ainda estava em teste, perguntei se await era um operador de prefixo e recebi uma resposta do PM da linguagem C #. Como há uma discussão sobre se Rust deve usar um operador de prefixo, achei que seria útil postar essa resposta aqui. De Por que 'await' é um operador de prefixo em vez de um operador de postfix? :

Como você pode imaginar, a sintaxe das expressões de await foi um grande ponto de discussão antes de decidirmos o que está por aí :-). No entanto, não consideramos muito os operadores postfix. Existe algo sobre o postfix (cf. calculadores HP e a linguagem de programação Forth) que torna as coisas mais simples em princípio e menos acessíveis ou legíveis na prática. Talvez seja apenas a forma como a notação matemática faz uma lavagem cerebral em nós como crianças ...

Definitivamente, descobrimos que o operador de prefixo (com seu sabor literalmente imperativo - "faça isso!") Era de longe o mais intuitivo. A maioria de nossos operadores unários já são prefixos, e await parece se adequar a isso. Sim, ele se afoga em expressões complexas, mas o mesmo acontece com a ordem de avaliação em geral, devido ao fato de que, por exemplo, a aplicação de função também não é pós-fixada. Você primeiro avalia os argumentos (que estão à direita) e depois chama a função (que está à esquerda). Sim, há uma diferença na sintaxe do aplicativo de função em C # vem com parênteses já embutidos, enquanto para await você geralmente pode removê-los.

O que vejo amplamente (e eu mesmo adotei) em torno de await é um estilo que usa muitas variáveis ​​temporárias. Eu tendo a preferir

var bResult = await A().BAsync();
var dResult = await bResult.C().DAsync();
dResult.E()

ou algo assim. Em geral, eu normalmente evitaria ter mais de um await em todas as expressões, exceto as mais simples (ou seja, eles são todos argumentos para a mesma função ou operador; provavelmente, esses são bons) e evito expressões de await entre parênteses, preferindo usar locais extras para ambos os trabalhos .

Faz sentido?

Mads Torgersen, PM em linguagem C #

Minha experiência pessoal como desenvolvedor C # é que a sintaxe me leva a usar esse estilo de instruções múltiplas e que isso torna o código assíncrono muito mais difícil de ler e escrever do que o equivalente síncrono.

@yazaddaruvala

Eu não vejo da mesma forma. Eu vejo isso sempre sendo um compromisso entre explícito e implícito

Ainda é explícito. Posso criar um link de um bom artigo sobre o assunto .

Eu diria que o compilador deve errar. Há uma enorme diferença de tipo que não pode ser inferida. Enquanto isso, o exemplo com Vecnão é resolvido por nenhuma das sintaxes neste tópico.

Por que haveria um erro? Estou feliz por ter Vec<impl future> , que eu poderia então juntar. Você propõe limitações extras sem motivo.

Eu diria que o Vecé um exemplo pobre, ou devemos manter todas as sintaxes propostas no mesmo padrão.

Devemos examinar cada caso. Não podemos simplesmente ignorar casos extremos porque "meh, você sabe, ninguém escreve isso de qualquer maneira". O design da linguagem trata principalmente de casos extremos.

@chescock: Eu concordo com você, mas dito antes, Rust tem uma grande diferença do C # aqui: em C # você nunca escreve (await FooAsync()).Bar() . Mas em Rust você faz. E estou falando sobre ? . Em C #, você tem uma exceção implícita que é propagada por meio de chamadas assíncronas. Mas na ferrugem você tem que ser explícito e escrever ? no resultado da função depois que ele foi aguardado.

Claro, você pode pedir aos usuários que escrevam

let foo = await bar();
let bar = await foo?.baz();
let bar = bar?;

mas é muito mais estranho que

let foo = await? bar();
let bar = await? foo.baz();

Parece muito melhor, mas requer a introdução de uma nova combinação de await e ? doint (await expr)? . Além disso, se tivermos alguns outros operadores, poderíamos escrever await?&@# e fazer todas as combinações funcionarem juntas ... Parece um pouco complicado.

Mas então podemos apenas colocar o await como um postfix e ele se encaixará naturalmente na linguagem atual:

let foo = bar() await?;
let bar = foo.baz() await?;

agora await? são dois tokens separados, mas eles funcionam juntos. Você pode ter await?&@# e não vai se preocupar em hackea-lo no próprio compilador.

Claro, parece um pouco mais estranho do que a forma de prefixo, mas, dito isso, é tudo sobre a diferença Rust / C #. Podemos usar a experiência C # para ter certeza de que precisamos de uma sintaxe de espera explícita que provavelmente terá uma palavra-chave separada, mas não devemos seguir cegamente o mesmo caminho e ignorar as diferenças Rust / C #.

Fui um proponente do prefixo await por um longo tempo e até convidei desenvolvedores de linguagem C # para o tópico (então temos informações mais recentes do que em 2011 😄), mas agora acho que o postfix await palavra-chave é a melhor abordagem.

Não se esqueça que há um noturno, então podemos refazê-lo mais tarde se encontrarmos uma maneira melhor.

Ocorreu-me que podemos obter o melhor dos dois mundos com uma combinação de:

• um prefixo async palavra-chave
• um recurso geral de macro Postfix

Que juntos permitiriam uma macro postfix .await!() ser implementada sem a mágica do compilador.

No momento, uma macro postfix .await!() exigiria mágica do compilador. No entanto, se uma variante de prefixo da palavra-chave await fosse estabilizada, isso não seria mais verdade: a macro pós-fixada .await!() poderia ser implementada trivialmente como uma macro que prefixava seu argumento (uma expressão) com a palavra-chave await e envolveu tudo entre colchetes.

Vantagens desta abordagem:

• O prefixo await palavra-chave está disponível e acessível para usuários familiarizados com essa construção em outros idiomas.
• A palavra-chave assíncrona de prefixo pode ser usada onde for desejável fazer com que a natureza assíncrona de uma expressão "se destaque".
• Haveria uma variante pós-fixada .await!() , que poderia ser usada em situações de encadeamento, ou qualquer outra situação onde a sintaxe do prefixo seja estranha.
• Não haveria necessidade de mágica de compilador (potencialmente inesperada) para a variante postfix (caso contrário, seria um problema para o campo postfix, método ou opções de macro).
• Macros Postfix também estariam disponíveis para outras situações (como .or_else!(continue) ), que por coincidência precisam da sintaxe de macro Postfix por motivos semelhantes (caso contrário, eles exigem que a expressão anterior seja encapsulada de uma maneira estranha e ilegível).
• A palavra-chave do prefixo await pode ser estabilizada de forma relativamente rápida (permitindo que o ecossistema se desenvolva) sem que tenhamos que esperar pela implementação de macros pós-fixadas. Mas, de médio a longo prazo, ainda deixaríamos em aberto a possibilidade de uma sintaxe pós-fixada para aguardar.

@nicoburns , @ H2CO3 ,

Não devemos implementar operadores de fluxo de controle como await!() e .or_else!(continue) como macros, porque da perspectiva do usuário não há razão significativa para fazer isso. De qualquer forma, em ambas as formas, os usuários teriam exatamente os mesmos recursos e deveriam aprender os dois; no entanto, se esses recursos fossem implementados como macros, os usuários também se preocupariam com o porquê de serem implementados dessa forma. É impossível não notar isso, porque haveria apenas uma diferença bizarra e artificial entre operadores regulares de primeira classe e operadores regulares implementados como macros (já que macros por si só são de primeira classe, mas coisas implementadas por elas não são).

É exatamente a mesma resposta que para . antes de await : não precisamos disso. As macros não podem imitar o fluxo de controle de primeira classe: elas têm formas diferentes, têm casos de uso diferentes, têm realces diferentes, funcionam de maneira diferente e são percebidas de maneira completamente diferente.

Para os recursos .await!() e .or_else!(continue) existe uma solução adequada e ergonômica com belas sintaxes: await palavra-chave e none -operador de coalescência. Devemos preferir implementá-los em vez de algo genérico, raramente usado e feio com aparência de macros pós-fixadas.

Não há razão para usar macros, já que não há algo complicado como format!() , não há algo raramente usado como include_bytes!() , não há um DSL personalizado, não há uma remoção de duplicação no código do usuário, há não é necessária uma sintaxe semelhante a vararg, não há necessidade de algo parecer diferente e não podemos usar essa forma apenas porque é possível.

Não devemos implementar operadores de fluxo de controle como macros porque, da perspectiva do usuário, não há nenhuma razão significativa para fazer isso.

try!() foi implementado como uma macro. Havia uma razão perfeitamente boa para isso.

Já descrevi qual seria o motivo para fazer await uma macro - não há necessidade de um novo elemento de linguagem se um recurso existente também puder atingir o objetivo.

não há algo complicado como format!()

Eu discordo: format!() não é sobre complicações, é sobre verificação em tempo de compilação. Se não fosse pela verificação em tempo de compilação, poderia ser uma função.

A propósito, eu não sugeri que deveria ser uma macro postfix. (Acho que não deveria.)

Para ambos os recursos existe uma solução adequada e ergonômica com belas sintaxes

Não devemos dar a cada chamada de função, expressão de controle de fluxo ou recurso de conveniência secundária sua própria sintaxe muito especial. Isso só resulta em uma linguagem inchada, cheia de sintaxe sem motivo, e é exatamente o oposto de "bela".

(Eu disse o que podia; não vou mais responder a este aspecto da pergunta.)

@nicoburns

Ocorreu-me que podemos obter o melhor dos dois mundos com uma combinação de:

• um prefixo await palavra-chave
• um recurso geral de macro Postfix

Isso implica fazer de await uma palavra-chave contextual em oposição à palavra-chave real que é atualmente. Eu não acho que devemos fazer isso.

Que juntos permitiriam uma macro postfix .await!() ser implementada sem a mágica do compilador.

Esta é uma solução mais complexa em termos de implementação do que foo await ou foo.await (especialmente o último). Ainda há "magia", tanto dela; você acabou de fazer uma manobra contábil .

Vantagens desta abordagem:

• O prefixo await palavra-chave está disponível e acessível para usuários familiarizados com essa construção em outros idiomas.

Se vamos adicionar .await!() mais tarde, estamos apenas dando aos usuários mais para aprender (tanto await foo quanto foo.await!() ) e agora os usuários perguntarão "qual devo usar quando..". Isso parece usar mais do orçamento de complexidade do que foo await ou foo.await como as soluções individuais fariam.

• Macros Postfix também estariam disponíveis para outras situações (como .or_else!(continue) ), que por coincidência precisam da sintaxe de macro Postfix por razões semelhantes (caso contrário, eles exigem que a expressão anterior seja encapsulada de uma forma estranha e ilegível).

Acredito que as macros postfix têm valor e devem ser adicionadas à linguagem. Isso não significa, entretanto, que eles precisam ser usados ​​para await ing; Como você mencionou, há .or_else!(continue) e muitos outros lugares onde macros postfix seriam úteis.

• O prefixo await palavra-chave pode ser estabilizado relativamente rapidamente (permitindo que o ecossistema se desenvolva) sem que tenhamos que esperar a implementação de macros pós-fixadas. Mas, de médio a longo prazo, ainda deixaríamos em aberto a possibilidade de uma sintaxe pós-fixada para aguardar.

Não vejo valor em "deixar possibilidades abertas"; o valor do postfix para composição, experiência IDE, etc. é conhecido hoje. Não estou interessado em "estabilizar await foo hoje e espero que possamos chegar a um consenso sobre foo.await!() amanhã".

@ H2CO3

try!() foi implementado como uma macro. Havia uma razão perfeitamente boa para isso.

try!(..) foi descontinuado, o que significa que o consideramos impróprio para o idioma, em particular porque não era pós-fixado. Usá-lo como um argumento - que não seja para o que não devemos fazer - parece estranho. Além disso, try!(..) é definido sem qualquer suporte do compilador .

A propósito, eu não sugeri que deveria ser uma macro postfix. (Acho que não deveria.)

await não é "cada um ..." - em particular, não é um recurso de conveniência menor ; em vez disso, é um recurso importante da linguagem que está sendo adicionado.

@phaylon

Além disso, com as discussões recentes sobre como complicar a gramática e os problemas que isso causará para o conjunto de ferramentas, pode não ser uma boa ideia confiar que IDEs / editores acertam as coisas.

A sintaxe foo.await tem como objetivo reduzir os problemas de ferramentas, pois qualquer editor com qualquer aparência de bom suporte para Rust já entenderá a forma .ident . O que o editor precisa fazer é apenas adicionar await à lista de palavras-chave. Além disso, bons IDEs já possuem autocompletar de código baseado em . - então, parece mais simples estender RLS (ou equivalentes ...) para fornecer await como a primeira sugestão quando o usuário digitar . após my_future .

Quanto a complicar a gramática, .await tem menos probabilidade de complicar a gramática, uma vez que apoiar .await na sintaxe é essencialmente analisar .$ident e não errar em ident == keywords::Await.name() .

A sintaxe foo.await visa reduzir os problemas de ferramentas, pois qualquer editor com qualquer aparência de bom suporte para Rust já entenderá a forma .ident. O que o editor precisa fazer é apenas adicionar await à lista de palavras-chave. Além disso, bons IDEs já possuem o auto-completar de código baseado em. - então parece mais simples estender RLS (ou equivalentes ...) para fornecer await como a primeira sugestão quando o usuário digita. depois do meu_futuro.

Eu apenas acho que isso está em desacordo com a discussão de gramática. E o problema não é agora, mas daqui a 5, 10, 20 anos, depois de algumas edições. Mas, como espero que você tenha percebido, também mencionei que mesmo que uma palavra-chave seja destacada, os pontos de espera podem passar despercebidos se outras palavras-chave estiverem envolvidas.

Quanto a complicar a gramática, .await tem menos probabilidade de complicar a gramática, visto que o suporte a .await na sintaxe é essencialmente analisar. $ Ident e não gerar erros em ident == keywords :: Await.name ().

Acho que a honra pertence a await!(future) , pois já é totalmente suportada pela gramática.

@Centril try! eventualmente se tornou redundante porque o operador ? pode fazer estritamente mais. Não é "impróprio para o idioma". Você pode não gostar , o que eu aceito. Mas para mim é na verdade uma das melhores coisas que Rust inventou e foi um dos seus argumentos de venda. E eu sei que é implementado sem suporte do compilador - mas não consigo ver como isso é relevante ao discutir se ele executa ou não o fluxo de controle. Ele faz, independentemente.

esperar não é "cada um ..."

Mas outros mencionados aqui (por exemplo, or_else ) são, e meu ponto ainda se aplica aos principais recursos de qualquer maneira. Adicionar sintaxe apenas para adicionar sintaxe não é uma vantagem, então sempre que houver algo que já funcione em um caso mais geral, deve-se preferir em vez de inventar uma nova notação. (Eu sei que o outro argumento contra macros é que "elas não são pós-fixadas". Eu simplesmente não acho que os benefícios de await ser seu próprio operador pós-fixada são altos o suficiente para justificar o custo. Sobrevivemos a chamadas de funções aninhadas. ficará igualmente bem após ter escrito algumas macros aninhadas.)

Na quarta-feira, 23 de janeiro de 2019 às 09:59:36 +0000, Mazdak Farrokhzad escreveu:

• Macros Postfix também estariam disponíveis para outras situações (como .or_else!(continue) ), que coincidentemente precisam da sintaxe de macro Postfix por razões semelhantes (caso contrário, eles exigem que a expressão anterior seja encapsulada de uma forma estranha e ilegível).

Acredito que as macros postfix têm valor e devem ser adicionadas à linguagem. Isso não significa, entretanto, que eles precisam ser usados ​​para await ing; Como você mencionou, há .or_else!(continue) e muitos outros lugares onde macros postfix seriam úteis.

A principal razão para usar .await!() é que se parecer com uma macro torna
é claro que pode afetar o fluxo de controle.

.await parece com um acesso de campo, .await() parece com uma função
chamada, e nem os acessos de campo nem as chamadas de função podem afetar o controle
fluxo. .await!() parece uma macro e as macros podem afetar o controle
fluxo.

@joshtriplett I não afeta o fluxo de controle no sentido padrão. Esse é o fato básico para justificar que o verificador de empréstimo deve funcionar em futuros conforme definido (e pin é o raciocínio como ). Do ponto de vista da execução de função local, a execução de await é como a maioria das outras chamadas de função. Você continua de onde parou e tem um valor de retorno na pilha.

Eu apenas acho que isso está em desacordo com a discussão de gramática. E o problema não é agora, mas daqui a 5, 10, 20 anos, depois de algumas edições.

Não tenho ideia do que você quer dizer com isso.

Acho que a honra pertence a await!(future) , pois já é totalmente suportada pela gramática.

Eu entendo, mas neste ponto, devido às inúmeras outras desvantagens dessa sintaxe, acho que ela está efetivamente descartada.

@Centril try! eventualmente se tornou redundante porque o operador ? pode fazer estritamente mais. Não é "impróprio para o idioma". Você pode não gostar disso, porém, eu aceito.

Está explicitamente obsoleto e, além disso, é um erro difícil escrever try!(expr) no Rust 2018. Decidimos coletivamente fazer isso e, portanto, foi considerado impróprio.

O principal motivo para usar .await!() é que a aparência de uma macro deixa claro que pode afetar o fluxo de controle.

.await parece com um acesso de campo, .await() parece com uma chamada de função e nem os acessos de campo nem as chamadas de função podem afetar o fluxo de controle.

Eu acredito que a distinção é algo que os usuários aprenderão com relativa facilidade, especialmente porque .await geralmente será seguido por ? (que é o fluxo de controle local da função). Quanto às chamadas de função, e como mencionado acima, acho que é justo dizer que os métodos iterativos são uma forma de fluxo de controle. Além disso, só porque uma macro pode afetar o fluxo de controle, não significa que o fará . Muitas macros não (por exemplo, dbg! , format! , ...). O entendimento de que .await!() ou .await afetará o fluxo de controle (embora em um sentido muito mais fraco do que ? , de acordo com a nota de await si.

@Centril

Isso envolve fazer a espera uma palavra-chave contextual em oposição à palavra-chave real que é atualmente. Eu não acho que devemos fazer isso.

Eek. Isso é um pouco doloroso. Talvez a macro pudesse ter um nome diferente, como .wait!() ou .awaited!() (o último é muito bom, pois deixa claro que se aplica à expressão anterior).

"O que, juntos, permitiria que uma macro postfix .await! () Fosse implementada sem a mágica do compilador."
Esta é uma solução mais complexa em termos de implementação do que foo await ou foo.await (especialmente o último). Ainda há "magia", tanto dela; você acabou de fazer uma manobra contábil.

Além disso, try! (..) é definido sem qualquer suporte do compilador.

E se tivéssemos uma palavra-chave de prefixo await e macros pós-fixadas, .await!() (talvez com um nome diferente) também poderia ser implementado sem o suporte do compilador, certo? Claro que a palavra-chave await si ainda implicaria uma quantidade significativa de mágica do compilador, mas isso seria simplesmente aplicado ao resultado de uma macro, e não é diferente do relacionamento de try!() com o return palavra-chave.

Se vamos adicionar .await! () Mais tarde, estamos apenas dando aos usuários mais para aprender (ambos await foo e foo.await! ()) E agora os usuários perguntarão "o que devo usar quando ..". Isso parece usar mais do orçamento de complexidade do que foo await ou foo.await como soluções únicas fariam.

Acho que a complexidade que isso adiciona ao usuário é mínima (complexidade de implementação pode ser outro assunto, mas se quisermos macros pós-fixadas de qualquer maneira ...). Ambas as formas são lidas intuitivamente, de forma que, ao ler qualquer uma delas, fique claro o que está acontecendo. Quanto a qual escolher ao escrever o código, os documentos poderiam simplesmente dizer algo como:

"Existem duas maneiras de esperar um Futuro em Ferrugem: await foo.bar(); e foo.bar().await!() . Qual usar é uma preferência estilística e não faz diferença para o fluxo de execução"

Não vejo valor em "deixar possibilidades abertas"; o valor do postfix para composição, experiência IDE, etc. é conhecido hoje.

Isso é verdade. Acho que, para mim, é mais uma questão de garantir que nossa implementação não exclua a possibilidade de termos uma linguagem mais unificada no futuro.

Não tenho ideia do que você quer dizer com isso.

Não importa muito. Mas, em geral, também prefiro quando a sintaxe é óbvia sem um bom destaque. Portanto, as coisas se destacam em git diff e em outros contextos semelhantes.

Em teoria, sim, e para programas triviais sim, mas na realidade os programadores
precisam saber onde estão seus pontos de suspensão.

Para um exemplo simples, você poderia segurar um RefCell em um ponto de suspensão e
o comportamento do seu programa será diferente do que se o RefCell fosse
liberado antes do ponto de suspensão. Em grandes programas, haverá
inúmeras sutilezas como essa, onde o fato de a função atual
está suspendendo é uma informação importante.

Na quarta-feira, 23 de janeiro de 2019 às 14h21 HeroicKatora [email protected]
escrevi:

@joshtriplett https://github.com/joshtriplett I não afeta o controle
fluxo no sentido padrão. Este é o fato básico para justificar que o
O verificador de empréstimo deve funcionar em futuros conforme definido. Do ponto de vista do
execução de função local, a execução de await é como qualquer outra chamada de função.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/rust-lang/rust/issues/57640#issuecomment-456989262 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ABGmeqcr2g4olxQhH9Fb9r6g3XRaFUu2ks5vGOBkgaJpZM4aBlba
.

Na quarta-feira, 23 de janeiro de 2019 às 02:26:07 PM -0800, Mazdak Farrokhzad escreveu:

O principal motivo para usar .await!() é que a aparência de uma macro deixa claro que pode afetar o fluxo de controle.

.await parece com um acesso de campo, .await() parece com uma chamada de função e nem os acessos de campo nem as chamadas de função podem afetar o fluxo de controle.

Acredito que a distinção é algo que os usuários aprenderão com relativa facilidade

Por que eles deveriam?

Acredito que a distinção seja algo que os usuários aprenderão com relativa facilidade, especialmente porque .await geralmente é seguido por? (que é o fluxo de controle local da função).

Freqüentemente, sim, mas nem sempre, e a sintaxe definitivamente deve funcionar para casos em que esse não é o caso.

Quanto às chamadas de função, e como mencionado acima, acho que é justo dizer que os métodos iterativos são uma forma de fluxo de controle.

Não da mesma forma que return ou ? (ou mesmo break ) são. Seria muito surpreendente se uma chamada de função pudesse retornar dois níveis acima da função que a chamou (uma das razões pelas quais Rust não tem exceções é precisamente porque isso é surpreendente), ou quebrar um loop na chamada função.

Além disso, só porque uma macro pode afetar o fluxo de controle, não significa que o fará. Muitas macros não (por exemplo, dbg !, format !, ...). O entendimento de que .await! () Ou .await afetará o fluxo de controle (embora em um sentido muito mais fraco do que?, De acordo com a nota de

Eu não gosto nada disso. Efetuar o fluxo de controle é um efeito colateral muito importante . Deve ter uma forma sintática diferente para construções que normalmente não podem fazer isso. As construções que podem fazer isso no Rust são: palavras-chave ( return , break , continue ), operadores ( ? ) e macros (avaliando para um das outras formas). Por que turvar as águas adicionando uma exceção?

@ejmahler Não vejo como segurar um RefCell é diferente para a comparação com uma chamada de função normal. Também pode ser que a função interna queira adquirir o mesmo RefCell. Mas ninguém parece ter um grande problema em não compreender imediatamente o gráfico de chamadas potencial completo. Da mesma forma, os problemas com o esgotamento da pilha não recebem nenhuma preocupação especial que você deva ter para anotar o espaço de pilha fornecido. Aqui a comparação seria favorável para co-rotinas! Devemos tornar as chamadas de função normais mais visíveis se não estiverem embutidas? Precisamos de chamadas de cauda explícitas para controlar esse problema cada vez mais difícil com as bibliotecas?

A resposta é, imho, que o maior risco ao usar o RefCell e esperar é a falta de familiaridade. Quando as outras questões acima podem ser abstraídas do hardware, acredito que nós, como programadores, também podemos aprender a não nos agarrar ao RefCell etc. em todos os pontos de rendimento, exceto onde for examinado.

Na quarta-feira, 23 de janeiro de 2019 às 10:30:10 +0000, Elliott Mahler escreveu:

Em teoria, sim, e para programas triviais sim, mas na realidade os programadores
precisam saber onde estão seus pontos de suspensão.

: +1:

@HeroicKatora

Uma diferença crítica é a quantidade de código que você precisa inspecionar, quantas
possibilidades que você tem que considerar. Os programadores já estão acostumados a
certificando-se de que nada que eles chamem também use um RefCell que eles verificaram
Fora. Mas com o await, em vez de inspecionar uma única pilha de chamadas, não temos
controle sobre o que é executado durante o await - literalmente qualquer linha do
programa pode ser executado. Minha intuição me diz que o programador médio é
muito menos equipados para lidar com essa explosão de possibilidades, pois
tem que lidar com isso com muito menos frequência.

Para outro exemplo de pontos de suspensão sendo informações críticas, no jogo
programação, normalmente escrevemos corrotinas que devem ser retomadas
uma vez por quadro, e mudamos o estado do jogo em cada currículo. Se negligenciarmos um
ponto de suspensão em uma dessas corrotinas, podemos deixar o jogo em um
estado para vários quadros.

Tudo isso pode ser tratado dizendo "seja mais inteligente e faça menos
erros ”, é claro, mas essa abordagem historicamente não funciona.

Na quarta-feira, 23 de janeiro de 2019 às 14h44 Josh Triplett [email protected]
escrevi:

Na quarta-feira, 23 de janeiro de 2019 às 10:30:10 +0000, Elliott Mahler escreveu:

Em teoria, sim, e para programas triviais sim, mas na realidade os programadores
precisam saber onde estão seus pontos de suspensão.

: +1:

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/rust-lang/rust/issues/57640#issuecomment-456995913 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ABGmep05nhZizdE5xil4FsnpONJCxqn-ks5vGOXhgaJpZM4aBlba
.

Para outro exemplo de pontos de suspensão sendo informações críticas, na programação de jogos, normalmente escrevemos corrotinas que devem ser retomadas uma vez por quadro e mudamos o estado do jogo em cada retomada. Se ignorarmos um ponto de suspensão em uma dessas corrotinas, podemos deixar o jogo em um estado interrompido por vários quadros.

Se você soltar a chave em um SlotMap, você perderá memória. A linguagem em si não ajuda você com isso inerentemente. O que eu quero dizer é que seus exemplos de como await não está vagamente visível o suficiente (desde que seja uma palavra-chave, sua ocorrência será única) não parecem generalizar para problemas que não ocorreram para outros recursos. Eu acho que você deve avaliar esperar menos sobre quais características a linguagem oferece imediatamente e mais sobre como torna possível para você expressar suas próprias características. Avalie suas ferramentas e aplique-as. Sugerir uma solução para o estado do jogo e como isso é resolvido suficientemente bem: Escreva um invólucro que afirme no retorno que o estado do jogo de fato marcou a quantidade necessária, async permite que você peça emprestado seu próprio estado para essa causa. Banir outras esperas nesse código compartimentado.

A explosão de estado no RefCell não vem de você não verificar se ele não é usado em outro lugar, mas de outros pontos de código, não sabendo que você confiou naquele invariante e adicionando-o silenciosamente. Estes são endereçados da mesma forma, documentação, comentários, embalagem correta.

Segurar RefCell não é muito diferente de segurar Mutex ao fazer o bloqueio de io. Você pode obter um deadlock, que é pior e mais difícil de depurar do que um pânico. E ainda não anotamos operações de bloqueio com a palavra-chave block explícita. :).

Compartilhar RefCell entre funções assíncronas limitará bastante sua usabilidade geral ( !Send ), então não acho que será comum. E RefCell geralmente deve ser evitado e, quando usado, emprestado pelo menor tempo possível.

Portanto, não acho que arrastar RefCell acidentalmente sobre um ponto de rendimento seja um grande negócio.

Se ignorarmos um ponto de suspensão em uma dessas corrotinas, podemos deixar o jogo em um estado interrompido por vários quadros.

Corrotinas e funções assíncronas são uma coisa diferente. Não estamos tentando tornar yield implícito.

Para qualquer um a favor da sintaxe da macro em vez da sintaxe da palavra-chave aqui: Descreva o que é sobre await que significa que deveria ser uma macro e como isso é diferente de, digamos, while , que _poderia_ ter acabou de ser uma macro while! ( mesmo usando apenas macro_rules! ; nenhuma caixa especial).

Edit: Isso não está sendo retórico. Estou genuinamente interessado em tal coisa, da mesma forma que pensei que queria executar para aguardar primeiro (como C #), mas o RFC me convenceu do contrário.

Para qualquer um a favor da sintaxe da macro em vez da sintaxe da palavra-chave aqui: Descreva do que se trata await, o que significa que deveria ser uma macro e como isso é diferente de, digamos, while, que poderia ter sido há pouco! macro (mesmo usando apenas macro_rules !; nenhum caso especial em tudo).

Eu concordo principalmente com esse raciocínio, e quero usar uma palavra-chave para sintaxe de prefixo.

No entanto, conforme descrito acima (https://github.com/rust-lang/rust/issues/57640#issuecomment-456990831), eu sou a favor de também ter uma macro postfix para a sintaxe postfix (talvez .awaited!() para evitar conflitos de nome com a palavra-chave do prefixo). Meu raciocínio é em parte que torna as coisas mais simples ter uma palavra-chave que só pode ser usada de uma maneira, e salvando outras variações para macros, mas sendo principalmente que, pelo que posso ver, ninguém foi capaz de sugerir um postfix sintaxe de palavra-chave que eu consideraria aceitável:

• foo.bar().await e foo.bar().await() seriam tecnicamente palavras-chave, mas eles se parecem com um acesso de campo ou chamada de método, e não acho que tal construção de modificação de fluxo de controle deva ser escondida assim.
• foo.bar() await é apenas confuso, especialmente com mais encadeamentos, como foo.bar() await.qux() . Nunca vi uma palavra-chave usada como um postfix assim (tenho certeza que existem, mas na verdade não consigo pensar em um único exemplo em qualquer idioma que conheço de palavras-chave que funcionem assim). E eu acho que parece muito confuso como se o await se aplicasse a qux() não a foo.bar() .
• foo.bar()@await ou alguma outra pontuação pode funcionar. Mas não é particularmente agradável e parece bastante ad-hoc. Na verdade, não acho que haja problemas significativos com essa sintaxe (ao contrário das opções acima). Eu apenas sinto que quando começamos a adicionar sigilos, o equilíbrio começa a se inclinar para o abandono da sintaxe customizada, e para que ela seja uma macro.

Vou reiterar uma ideia anterior mais uma vez, embora ajustada com novos pensamentos e considerações, então tento permanecer em silêncio.

await como uma palavra-chave só é válida dentro de uma função async qualquer maneira, então devemos permitir o identificador await outro lugar. Se uma variável é nomeada await em um escopo externo, ela não pode ser acessada de dentro de um bloco async menos que seja usado como um identificador bruto. Ou, por exemplo, a macro await! .

Além disso, adaptar a palavra-chave como essa permitiria meu ponto principal: devemos permitir a combinação e correspondência de geradores e funções assíncronas, assim:

// imaginary generator syntax stolen from JavaScript
fn* my_generator() -> T {
    yield some_value;

    // explicit return statements are only included to 
    // make it clear the generator/async functions are finished.
    return another_value;
}

// `await` keyword would not be allowed here, but the `yield` keyword is
#[async]
fn* my_async_generator() -> Result<T, E> {
    let item = some_op().await!()?; // uses the `.await!()` macro
    // which would really just use `yield` internally, but with the pinning API
    // same as the current nightly macro.

    yield future::ok(item.clone());

    return Ok(item);
}

// `yield` would not be allowed here, but the `await` keyword is.
async fn regular_async() -> Result<T, E> {
   let some_op = async || { /*...*/ };

   let item = await? some_op();

   return Ok(item);
}

Eu acredito que isso é suficientemente transparente para usuários extremamente avançados que querem fazer coisas divertidas, mas permite que usuários novos e moderados usem apenas o necessário. 2 e 3, se usados ​​sem nenhuma instrução yield , são efetivamente idênticos.

Também acho que o prefixo await? é um ótimo atalho para adicionar ? ao resultado da operação assíncrona, mas isso não é estritamente necessário.

Se macros postfix se tornarem uma coisa oficial (o que eu espero que aconteçam), tanto await!(...) quanto .await!() podem coexistir, permitindo três maneiras equivalentes de fazer o Wait, para casos de uso e estilos específicos . Não acredito que isso adicionaria sobrecarga cognitiva, mas permitiria maior flexibilidade.

Idealmente, async fn e #[async] fn* poderiam até mesmo compartilhar o código de implementação para transformar o gerador subjacente em uma máquina de estado assíncrona.

Esses problemas deixaram claro que não existe um estilo preferido de verdade, então o melhor que posso esperar é fornecer níveis de complexidade limpos, flexíveis, legíveis e fáceis de abordar. Acho que o esquema acima é um bom compromisso para o futuro.

await como uma palavra-chave só é válida dentro de uma função async , portanto, devemos permitir que o identificador aguarde em outro lugar.

Não sei se isso é prático no Rust, dadas as macros higiênicas. Se eu chamar foo!(x.await) ou foo!(await { x }) quando quiser um expr , acho que não deveria ser ambíguo que a palavra-chave await é desejada - não await field ou a expressão literal await struct com abreviação de init de campo - mesmo em um método síncrono.

permitindo três maneiras equivalentes de fazer esperas

Por favor não. (Pelo menos em core . Obviamente, as pessoas podem criar macros em seus próprios códigos, se quiserem)

No momento, uma macro postfix .await! () Exigiria mágica do compilador. No entanto, se uma variante de prefixo da palavra-chave await fosse estabilizada, isso não seria mais verdade: a macro postfix .await! () Poderia ser implementada trivialmente como uma macro que prefixava seu argumento (uma expressão) com a palavra-chave await e envolvia tudo entre colchetes.

Notarei que isso é igualmente verdade - mas mais fácil! - na outra direção: se estabilizarmos a sintaxe da palavra-chave .await , as pessoas já podem fazer uma macro de prefixo awaited!() se não gostarem de postfix o suficiente.

Não gosto da ideia de adicionar várias variantes permitidas (como prefixo e pós-fixado), mas por um motivo um pouco diferente do que os usuários pedirão. Eu trabalho em uma empresa bastante grande e as brigas pelo estilo do código são reais. Eu gostaria de ter apenas uma forma óbvia e correta para usar. Afinal, o Zen do python pode estar certo com relação a esse ponto.

Não gosto da ideia de adicionar várias variantes permitidas (como prefixo e pós-fixado), mas por um motivo um pouco diferente do que os usuários pedirão. Eu trabalho em uma empresa bastante grande e as brigas pelo estilo do código são reais. Eu gostaria de ter apenas uma forma óbvia e correta para usar. Afinal, o Zen do python pode estar certo com relação a esse ponto.

Eu sei o que você quer dizer. No entanto, não há como impedir que os programadores definam suas próprias macros fazendo coisas como await!() . Estruturas semelhantes sempre serão possíveis. Então realmente HAVERÁ variantes diferentes de qualquer maneira.

Bem, não await!(...) pelo menos, pois isso seria um erro; mas se um usuário definir macro_rules! wait { ($e:expr) => { e.await }; } e usar isso como wait!(expr) então parecerá nitidamente unidiomático e provavelmente sairá de moda rapidamente. Isso diminui significativamente a probabilidade de variação no ecossistema e permite que os usuários aprendam menos estilos. Portanto, acho que o argumento de

@Centril Se alguém quiser fazer coisas ruins, dificilmente poderá ser impedido. E quanto a _await!() ou awai!() ?

ou, quando o identificador Unicode habilitado, algo como àwait!() .

...

@earthengine O objetivo é definir normas da comunidade (semelhante ao que fazemos com style lints e rustfmt ), não para evitar que várias pessoas façam coisas estranhas de propósito. Estamos lidando com probabilidades aqui, não garantias absolutas de não ver _await!() .

Vamos resumir e revisar os argumentos para cada sintaxe postfix:

• __ expr await (palavra-chave do Postfix) __: A sintaxe da palavra-chave do Postfix usa a palavra-chave await que já reservamos. Await é uma transformação mágica, e usar uma palavra-chave ajuda a se destacar de forma adequada. Não se parece com um acesso de campo ou um método ou chamada de macro, e não teremos que explicar isso como uma exceção. Ele se encaixa bem com as regras de análise atuais e com o operador ? . O espaço no encadeamento de métodos não é, sem dúvida, atribuição de tipo generalizada , uma RFC que parece ser aceita de alguma forma. No lado negativo, IDEs podem precisar fazer mais mágica para fornecer um preenchimento automático para await . As pessoas podem achar o espaço no encadeamento de métodos muito incômodo (embora @withoutboats tenha argumentado que isso pode ser uma vantagem), especialmente se o código não estiver formatado de forma que await termine cada linha. Ele usa uma palavra-chave que talvez pudéssemos evitar se adotássemos outra abordagem.

• __ expr.await (campo postfix) __: A sintaxe do campo Postfix aproveita o "poder do ponto" - parece natural no encadeamento e permite que os IDEs completem automaticamente await sem realizar outras operações (como como remover automaticamente o ponto ). É tão conciso quanto a palavra-chave Postfix. O ponto na frente de await pode tornar as instâncias dele mais fáceis de encontrar com grep. No lado negativo, parece um acesso de campo. Como um acesso de campo aparente, não há dica visual de que "isso faz alguma coisa".

• __ expr.await() (método postfix) __: A sintaxe do método Postfix é semelhante ao campo Postfix. Por outro lado, a sintaxe de chamada () indica ao leitor: "isso faz alguma coisa". Visto localmente, quase faz sentido da mesma maneira que uma chamada a um método de bloqueio resultaria na execução em um programa multi-threaded. No lado negativo, é um pouco mais longo e barulhento, e disfarçar o comportamento mágico de await como um método pode ser confuso. Podemos dizer que await é um método no mesmo sentido limitado que call/cc em Scheme é uma função. Como método, precisamos considerar se Future::await(expr) deve funcionar de forma consistente com o UFCS .

• __ expr.await!() (macro postfix) __: A sintaxe da macro Postfix aproveita de forma semelhante o "poder do ponto". A macro ! bang indica "isso pode fazer algo mágico." Por outro lado, isso é ainda mais barulhento e, embora as macros façam mágica, normalmente não fazem mágica ao código circundante como await faz. Também no lado negativo, assumindo que padronizamos uma sintaxe de macro postfix de propósito geral , pode haver problemas em continuar a tratar await como uma palavra-chave.

• __ expr@ , expr# , expr~ e outros símbolos de um único caractere__: Usar um único caractere como fazemos com ? maximiza a concisão e talvez crie uma sintaxe pós-fixada parece mais natural. Como acontece com ? , podemos descobrir que apreciamos essa concisão se await começar a permear nosso código. No lado negativo, até e a menos que a dor de ter nosso código repleto de await se torne um problema, é difícil ver um consenso se formando em torno das compensações inerentes à adoção de tal sintaxe.

Eu queria fazer uma postagem para agradecer a @traviscross por essas postagens de resumo! Eles foram consistentemente bem escritos e bem interligados. É muito apreciado. :coração:

Eu tenho uma ideia de que adicionando "operadores de pipe" como F #, os usuários podem usar prefixo ou pós-fixo (com diferença de sintaxe explícita).

// use `|>` for instance, Rust can choose other sigils if there are conflicts with current syntax
await expr
expr |> await

// and we can use this operator on normal function calls too
f(g(h(x))) 
x |> h |> g |> f
// this is more convenient than "postfix macro"
x.h!().g!().f!()