다른 언어가 await 구문을 처리하는 방법을 작성하는 것이 유용 할 것이라고 생각했습니다.

Kotlin

val result = task.await()

씨

var result = await task;

에프

let! result = task()

스칼라

val result = Await.result(task, timeout)

파이썬

result = await task

자바 스크립트

let result = await task;

C ++ (코 루틴 TR)

auto result = co_await task;

마구 자르기

$result = await task;

다트

var result = await task;

이 모든 것을 가지고 Rust 표현식이 여러 개의 연결 메서드를 생성 할 수 있음을 기억합시다. 대부분의 언어는 그렇게하지 않는 경향이 있습니다.

이 모든 것을 가지고 Rust 표현식이 여러 개의 연결 메서드를 생성 할 수 있음을 기억합시다. 대부분의 언어는 그렇게하지 않는 경향이 있습니다.

확장 방법을 지원하는 언어에는 이러한 기능이있는 경향이 있다고 말하고 싶습니다. 여기에는 Rust, Kotlin, C # (예 : 메서드 구문 LINQ 및 다양한 빌더) 및 F #이 포함되지만 후자는 동일한 효과를 위해 파이프 연산자를 많이 사용합니다.

순전히 내 일화이지만, 야생에서 Rust 코드에서 수십 개 이상의 메소드 체인 표현식을 정기적으로 실행하고 잘 읽고 실행됩니다. 나는 이것을 다른 곳에서 경험하지 못했습니다.

이 문제가 # 50547의 최상위 게시물 ( "대기에 대한 최종 구문"확인란 옆에 있음)에서 언급 된 것을보고 싶습니다.

Kotlin

val result = task.await()

Kotlin의 구문은 다음과 같습니다.

val result = doTask()

await 는 일류가 아닌 suspendable function 입니다.

말씀 해주셔서 감사합니다. Kotlin은 기본적으로 미래가 열망하기 때문에 더 암시 적이라고 느낍니다. 그러나이 방법을 사용하여 다른 지연된 블록을 대기하는 것은 지연된 블록의 일반적인 패턴입니다. 나는 확실히 그것을 여러 번했다.

@cramertj https://github.com/rust-lang/rust/issues/50547에 276 개의 댓글이 있으므로 여기에서 반복하지 않기 쉽도록 여기에 작성된 인수를 요약 할 수 있습니까? (아마 여기 OP에 추가할까요?)

Kotlin은 기본적으로 미래가 열망하기 때문에 더 암시 적이라고 느낍니다. 그러나이 방법을 사용하여 다른 지연된 블록을 대기하는 것은 지연된 블록의 일반적인 패턴입니다. 나는 확실히 그것을 여러 번했다.

약간의 컨텍스트 / 설명과 함께 두 사용 사례를 모두 추가해야 할 수도 있습니다.

또한 go-lang과 같은 암시 적 대기를 사용하는 다른 언어에는 무엇이 있습니까?

post-fix 구문을 선호하는 한 가지 이유는 호출자의 관점에서 await가 함수 호출과 매우 유사하게 동작하기 때문입니다. 흐름 제어를 포기하고 다시 가져 오면 결과가 스택에서 기다리고 있습니다. 어쨌든 함수 패란 테 시스를 포함하여 함수와 유사한 동작을 포용하는 구문을 선호합니다. 그리고이 동작이 동기화 블록과 비동기 블록 사이에서 일관되도록 첫 번째 실행에서 코 루틴의 구성을 분할하려는 좋은 이유가 있습니다.

그러나 암묵적 코 루틴 스타일에 대해 논의되고 있고 저는 명시 성의 편에있는 반면 코 루틴을 .await!() 는 보통 호출과 코 루틴 호출을 구분하려는 시도입니다.

따라서 포스트 픽스가 선호되는 이유에 대해 다소 새로운 관점을 제공 한 후, 구문에 대한 겸손한 제안 :

• future(?)
• 또는 future(await) 는 물론 자체 장단점이 있지만 덜 헷갈리는 것으로 받아 들여지는 것 같습니다. 게시물 하단을 참조하십시오.

다른 스레드에서 상당히 인기있는 예제를 적용합니다 ( logger.log 도 코 루틴이라고 가정하여 즉시 호출이 어떻게 보이는지 보여줍니다).

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
}

그리고 대안 :

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
}

읽을 수없는 코드를 방지하고 구문 분석을 돕기 위해 물음표와 열린 매개 변수 사이가 아닌 물음표 뒤의 공백 만 허용하십시오. 따라서 future(? ) 은 좋지만 future( ?) 는 그렇지 않습니다. 이 문제는 모든 현재 토큰을 이전과 같이 사용할 수있는 future(await) 의 경우에는 발생하지 않습니다.

다른 수정 후 연산자 (예 : 현재 ? -try)와의 상호 작용도 함수 호출에서와 같습니다.

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 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)
}

이것을 좋아하는 몇 가지 이유 :

• .await!() 와 비교하면 다른 용도로 사용할 수있는 회원을 암시하지 않습니다.
• 연결 및 ? 사용과 같은 자연스러운 호출 우선 순위를 따릅니다. 이것은 선행 수업의 수를 낮추고 학습에 도움이됩니다. 그리고 함수 호출은 (특성이 있더라도) 언어에서 항상 다소 특별했기 때문에 사용자 코드가 매우 유사한 구문과 효과를 가진 자신의 my_await!() 를 정의 할 수있을 것이라는 기대가 없습니다.
• 이는 재개시 더 많은 인수가 제공 될 것으로 예상하는 생성기뿐만 아니라 생성기와 스트림으로 일반화 할 수 있습니다. 본질적으로 이것은 FnOnce 처럼 작동하는 반면 Streams 는 FnMut 처럼 작동합니다. 추가 주장도 쉽게 조정할 수 있습니다.
• 이전에 현재 Futures 를 사용한 적이있는 사람들을 위해, 이것은 ? 와 함께 Poll 가 어떻게 작동 했어야했는지를 보여줍니다 (불행한 안정화 시퀀스 여기). 학습 단계로서 ? 기반 운영자가 제어 흐름을 전환 할 것으로 예상하는 것과 일치합니다. 반면에 (await) 는이를 만족시키지 못하지만 결국 함수는 항상 분기점에서 재개 될 것으로 예상합니다.
• 함수와 같은 구문을 사용하지만이 인수는 나와 동의하는 경우에만 좋습니다.

그리고 이것을 좋아하지 않는 이유 :

• ? 는 인수로 보이지만 표현식에도 적용되지 않습니다. 나는 이것이 적용되는 것처럼 보이는 토큰이 다소 정확한 개념 인 함수 호출 자체이므로 교육을 통해 해결할 수 있다고 생각합니다. 이것은 또한 구문이 모호하지 않다는 것을 긍정적으로 의미합니다.
• paranthesis와 ? 더 많은 (그리고 다른) 혼합은 구문 분석하기 어려울 수 있습니다. 특히 하나의 미래가 다른 미래의 결과를 반환하는 경우 : construct_future()(?)?(?)? . 그러나 fn 객체의 결과를 얻을 수 있다는 동일한 인수를 만들 수 있으며, 다음과 같은 표현식이 허용됩니다. foobar()?()?()? . 그럼에도 불구하고 나는 이것이 사용되거나 불만을 품은 것을 본 적이 없기 때문에 그러한 경우에 별도의 진술로 나누는 것이 거의 필요하지 않은 것 같습니다. 이 문제는 construct_future()(await)?(await)? 에도 존재하지 않습니다-
• future(?) 는 간결하고 여전히 다소 간결한 구문에서 가장 좋은 방법입니다. 그러나 그 이유는 코 루틴의 구현 세부 사항 (일시적으로 이력서에 반환 및 발송)에 기반을두고 있으므로 추상화에 적합하지 않을 수 있습니다. future(await) 는 await 를 키워드로 내재화 한 후에도 설명 할 수있는 대안이 될 수 있지만 인수 위치는 제게 삼키기가 약간 어렵습니다. 괜찮을 수 있으며 코 루틴이 결과를 반환 할 때 확실히 더 읽기 쉽습니다.
• 다른 함수 호출 제안과 간섭이 있습니까?
• 너 스스로? 당신은 그것을 좋아할 필요가 없습니다. 최소한이 간결한 post-fix 구문을 제안하지 않는 것은 낭비처럼 느껴졌습니다.

future(?)

Result 에는 특별한 것이 없습니다. Futures는 모든 Rust 유형을 반환 일부 선물은 Result 반환합니다.

그렇다면 Result 반환하지 않는 Futures에서는 어떻게 작동할까요?

내가 의미하는 바가 명확하지 않은 것 같습니다. future(?) 는 이전에 future.await!() 또는 이와 유사한 것으로 논의 된 것입니다. 결과를 반환하는 미래에도 분기하는 것은 future(?)? (제어 흐름을 조기에 포기할 수있는 두 가지 방법). 이렇게하면 미래 폴링 (?) 및 결과 테스트 ? 직교합니다. 편집 : 이에 대한 추가 예제를 추가했습니다.

결과를 반환하는 퓨처에 대한 분기도 future(?)?

명확히 해주셔서 감사합니다. 이 경우 나는 확실히 그것의 팬이 아닙니다.

즉, Future<Output = Result<_, _>> 를 반환하는 함수를 호출하면 foo()(?)? 와 같이 작성됩니다.

구문이 매우 많고 완전히 다른 두 가지 목적으로 ? 를 사용합니다.

무거운 ? 연산자에 대한 힌트라면 물론 새로 예약 된 키워드로 대체 할 수 있습니다. 나는 처음에 이것이 수수께끼 같은 유형의 실제 주장과 너무 비슷하다고 생각했지만, 그 절충안은 진술을 정신적으로 파싱하는 데 도움이 될 수 있습니다. 따라서 impl Future<Output = Result<_,_>> 대한 동일한 문은 다음과 같습니다.

• foo()(await)?

? 이 적절한 이유는 사용되는 내부 메커니즘이 다소 유사하다는 것입니다 (그렇지 않으면 현재 라이브러리에서 Poll 를 사용할 수 없음). 이것은 좋은 추상화의 요점을 놓칠 수 있습니다.

구문이 매우 무겁습니다.

나는 그것이 명백한 기다림의 요점이라고 생각합니까?

그것은 사용합니까? 완전히 다른 두 가지 목적을 위해.

예, foo()(await) -구문이 훨씬 더 좋을 것입니다.

이 구문은 클로저를 반환하는 함수를 호출 한 다음 JS에서 클로저를 호출하는 것과 같습니다.

"syntax-heavy"에 대한 나의 읽기는 "sigil-heavy"에 더 가깝습니다. ()(?)? 의 시퀀스를 보는 것은 상당히 엉망입니다. 이것은 원래 게시물에서 제기되었습니다.

paranthesis와 ? 더 많은 (그리고 다른) 혼합은 구문 분석하기 어려울 수 있습니다. 특히 하나의 미래가 다른 미래의 결과를 반환하는 경우 : construct_future()(?)?(?)?

그러나 fn 객체의 결과를 얻을 수 있다는 동일한 인수를 만들 수 있으며, 다음과 같은 표현식이 허용됩니다. foobar()?()?()? . 그럼에도 불구하고 나는 이것이 사용되거나 불만을 품은 것을 본 적이 없기 때문에 그러한 경우에 별도의 진술로 나누는 것이 거의 필요하지 않은 것 같습니다.

여기에 대한 반박은 다음과 같습니다 : 야생에서 -> impl Fn 를 몇 번이나 보셨습니까 ( -> Result<impl Fn() -> Result<impl Fn() -> Result<_, _>, _>, _> 제외)? 비동기 코드베이스에서 -> impl Future<Output = Result<_, _>> 를 몇 번이나 볼 것으로 예상합니까? 코드를 더 쉽게 읽을 수 있도록 희귀 한 impl Fn 반환 값의 이름을 지정하는 것은 임시 impl Future 반환 값의 상당 부분에 이름을 지정하는 것과 매우 다릅니다.

코드를 더 쉽게 읽을 수 있도록 희귀 한 impl Fn 반환 값의 이름을 지정하는 것은 임시 impl Future 반환 값의 상당 부분에 이름을 지정해야하는 것과 매우 다릅니다.

이 구문 선택이 결과 유형의 이름을 명시 적으로 지정해야하는 횟수에 어떻게 영향을 미치는지 모르겠습니다. await? future 와 다른 유형 추론에 영향을 미치지 않는다고 생각합니다.

그러나 여러분은 모두 여기에서 매우 좋은 점을 지적하고 더 많은 예제를 참조할수록 (원래 게시물은 항상 두 가지 구문 버전을 future(await) 더 의지합니다. 타이핑하는 것은 비합리적이지 않으며 이것이 불러 일으키려는 함수 호출 구문의 모든 명확성을 유지합니다.

몇 번이나 볼 것으로 예상합니까-> impl Future

> 비동기 코드베이스에서?

나는이 유형에 해당 볼 것으로 예상 (비동기 FN을 그 리턴 결과) 모든 시간, 모든 비동기 FNS의 가능성도 대부분, 당신이 기다리고있는 것은 심지어 IO 경우 때문에, 당신은 거의 확실하게 던지고있을거야 위쪽으로 IO 오류.

추적 문제에 대한 이전 게시물에 연결 하고 몇 가지 생각을 추가합니다.

이 구문에는 await 문자열을 포함하지 않는 구문이 허용 될 가능성이 거의 없다고 생각합니다. 이 시점에서이 기능에 대해 1 년 동안 작업 한 후에는 알려진 실행 가능한 대안의 장단점을 비교하여 새로운 구문을 제안하는 것보다 가장 좋은 방법을 찾는 것이 더 생산적이라고 생각합니다. 이전 게시물을 고려할 때 내가 생각하는 구문은 실행 가능합니다.

• 필수 구분 기호로 접두사가 대기합니다. 여기에서 구분 기호 (중괄호 또는 괄호 또는 둘 다 허용)에 대한 결정도 있습니다. 이들 모두는 고유 한 장단점이 있습니다. 즉, await(future) 또는 await { future } 입니다. 이렇게하면 우선 순위 문제가 완전히 해결되지만 구문 상 시끄럽고 두 구분자 옵션 모두 혼동의 원인이 될 수 있습니다.
• ? 와 관련된 "유용한"우선 순위로 접두어가 대기합니다. (즉, 그 대기는?보다 더 빡빡하게 묶입니다.) 이것은 코드를 읽는 일부 사용자를 놀라게 할 수 있지만 결과의 미래를 반환하는 함수는 미래의 결과를 반환하는 함수보다 압도적으로 더 일반적이라고 생각합니다.
• ? 에 대한 "명백한"우선 순위로 접두사를 기다립니다. (즉,? 기다리는 것보다 더 빡빡하게 묶습니다). 결합 된 await 및?에 대한 추가 구문 설탕 await? 운영자. 이 구문 설탕은이 우선 순위 순서를 실행 가능하게 만드는 데 필요하다고 생각합니다. 그렇지 않으면 모든 사람이 항상 (await future)? 쓸 것입니다. 이것은 제가 열거 한 첫 번째 옵션의 더 나쁜 변형입니다.
• 구문 공간이있는 접미사가 대기합니다. 이것은 두 연산자 사이에 명확한 시각적 순서를 가짐으로써 우선 순위 문제를 해결합니다. 이 솔루션에 대해 많은 측면에서 불안감을 느낍니다.

내 자신의 순위는 내가 문제를 조사 할 때마다 이러한 선택이 변경된다는 것을 알 수 있습니다. 현재로서는 설탕에 대한 명백한 우선 순위를 사용하는 것이 인체 공학, 친숙 함 및 이해력의 최상의 균형이라고 생각합니다. 그러나 과거에는 두 개의 다른 접두사 구문 중 하나를 선호했습니다.

논의를 위해 다음 네 가지 옵션에 이름을 지정하겠습니다.

이름 | 미래 | 결과의 미래 | 미래의 결과
--- | --- | --- | ---
필수 구분 기호 | await(future) 또는 await { future } | await(future)? 또는 await { future }? | await(future?) 또는 await { future? }
유용한 우선 순위 | await future | await future? | await (future?)
설탕이있는 명백한 우선 순위 | await future | await? future 또는 (await future)? | await future?
접미사 키워드 | future await | future await? | future? await

(이 옵션을 "postfix macro"와 같은 다른 postfix 구문과 구별하기 위해 특별히 "postfix keyword"를 사용했습니다.)

유용한 우선 순위에서 await future? 의 '축복'의 단점 중 하나이지만 후위 수정으로 작동하지 않는 다른 것들은 ? 로 표현식을 수동으로 변환하는 일반적인 패턴이 더 이상 적용되지 않을 수 있다는 것입니다. 또는 Future 가 호환 가능한 방식으로 Result 메소드를 명시 적으로 복제하도록 요구합니다. 놀랍습니다. 그들이 복제되면, 어느 결합자가 반환 된 미래를 위해 일하고 열망하는지가 갑자기 혼란스러워집니다. 즉, 암시 적 대기의 경우처럼 결합자가 실제로 수행하는 작업을 결정하는 것이 어려울 수 있습니다. (편집 : 실제로 ? 의 놀라운 대체가 의미하는 더 기술적 인 관점이있는 아래 두 개의 주석을 참조하십시오)

오류 사례에서 복구 할 수있는 예 :

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);
}

실제 수정 후 연산자에 대해서는이 문제가 발생하지 않습니다.

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);

이것들은 다른 표현식이며, 점 연산자는 "명백한 우선 순위" await 연산자보다 우선 순위가 높으므로 동등한 것은 다음과 같습니다.

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

이것은 or_recover 가 비동기인지 아닌지에 대해 정확히 동일한 모호성을 갖습니다. (내가 주장하는 것은 중요하지 않다. 당신은 표현이 전체적으로 비동기라는 것을 알고있다. 그리고 어떤 이유로 특정 부분이 비동기인지 알 필요가 있다면 or_recover 의 정의를 볼 수있다).

이것은 or_recover가 비동기인지 아닌지에 대해 정확히 동일한 모호성을 가지고 있습니다.

똑같지는 않습니다. unwrap_or_else 은 (는) 대기 중이기 때문에 코 루틴을 생성해야하므로 모호성은 get_result 가 코 루틴 (콤비 네이터가 빌드 됨)인지 아니면 Result<impl Future, _> (및 Ok 에는 이미 코 루틴이 포함되어 있고 Err 는 코 루틴을 빌드합니다). 둘 다 await 시퀀스 포인트를 join 이동하여 효율성 향상을 한 눈에 파악할 수 있다는 동일한 우려가 없습니다 await 암시 적 기다립니다. 그 이유는 어떤 경우에도이 중간 계산 은 동기화 되어야 하고 await 전에 유형에 적용 되어야 하고 코 루틴이 대기

이들은 다른 표현식입니다. 도트 연산자는 "명백한 우선 순위"await 연산자보다 우선 순위가 높으므로 동등한 것은 다음과 같습니다.

즉, 대체 혼란의 일부 ? 회복 동작으로의 위치 변경된 await 근본적으로한다. ? 구문의 컨텍스트에서 T expr 부분 표현식이 주어지면 변환에서 다음과 같은 의미를 예상합니다 ( T::unwrap_or_else 가 존재한다고 가정). :

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

그러나 '유용한 우선 순위'및 await expr? ( await expr T 산출 함)에서 대신

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

명백한 우선 순위에서이 변형은 더 이상 추가 괄호 없이는 전혀 적용되지 않지만 적어도 직감은 여전히 ​​'미래의 결과'를 위해 작동합니다.

그리고 콤비 네이터 시퀀스에서 서로 다른 두 지점에서 기다리는 더 흥미로운 경우는 어떻습니까? 접두사 구문을 사용하면 괄호가 필요하다고 생각합니다. Rust 언어의 나머지 부분은 '표현식이 왼쪽에서 오른쪽으로 평가됨'이 작동하도록 길게이 문제를 피하려고합니다. 이에 대한 한 가지 예는 자동 참조 마법입니다.

여러 대기 / 시도 / 결합 포인트가있는 더 긴 체인에서 이것이 더 나빠진다는 것을 보여주는 예제.

// 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)?;
}

내가 피하고 싶은 것은 C의 유형 구문 분석의 Rust 아날로그를 만드는 것입니다.
'포인터'와 '배열'결합 자에 대한 표현의 왼쪽과 오른쪽.

@withoutboats 스타일의 테이블 항목 :

| 이름 | 미래 | 결과의 미래 | 미래의 결과 |
|-|-|-|-|
| 필수 구분 기호 | await(future) | await(future)? | await(future?) |
| 유용한 우선 순위 | await future | await future? | await (future?) |
| 명백한 우선 순위 | await future | await? future | await future? |
| Postfix 호출 | future(await) | future(await)? | future?(await) |

| 이름 | 체인 |
|-|-|
| 필수 구분 기호 | await(await(foo())?.bar())? |
| 유용한 우선 순위 | await(await foo()?).bar()? |
| 명백한 우선 순위 | await? (await? foo()).bar() |
| Postfix 호출 | foo()(await)?.bar()(await) |

나는 여러 가지 이유로 기다림 접미사를 강력히 선호하지만 foo await.method() 은 (는) 혼란 스럽습니다.

먼저 비슷한 테이블을 보되 접미사 변형을 몇 개 더 추가합니다.

| 이름 | 미래 | 결과의 미래 | 미래의 결과 |
| ---------------------- | -------------------- | ----- ---------------- | --------------------- |
| 필수 구분 기호 | await { future } | await { future }? | await { future? } |
| 유용한 우선 순위 | await future | await future? | await (future?) |
| 명백한 우선 순위 | await future | await? future | await future? |
| 접미사 키워드 | future await | future await? | future? await |
| 접미사 필드 | future.await | future.await? | future?.await |
| 후위 방법 | future.await() | future.await()? | future?.await() |

이제 연결된 미래 표현식을 살펴 보겠습니다.

| 이름 | 결과의 연결 미래 |
| ---------------------- | -------------------------- ----------- |
| 필수 구분 기호 | await { await { foo() }?.bar() }? |
| 유용한 우선 순위 | await (await foo()?).bar()? |
| 명백한 우선 순위 | await? (await? foo()).bar() |
| 접미사 키워드 | foo() await?.bar() await? |
| 접미사 필드 | foo().await?.bar().await? |
| 후위 방법 | foo().await()?.bar().await()? |

이제 실제 예를 들어 reqwests 에서 연결 한 결과의 미래를 기다리고 싶을 수 있습니다 (내 선호하는 대기 양식 사용).

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

실제로 나는 모든 구분 기호가 접미사 구문에 대해 잘 보인다고 생각합니다.
let res: MyResponse = client.get("https://my_api").send()/await?.json()/await?;
그러나 나는 어떤 것을 사용할 지에 대한 강한 의견이 없습니다.

접미사 매크로 (예 : future.await!() )가 여전히 옵션 일 수 있습니까? 명확하고 간결하며 모호하지 않습니다.

| 미래 | 결과의 미래 | 미래의 결과 |
| --- | --- | --- |
| future.await! () | future.await! ()? | 미래? .await! () |

또한 postfix 매크로는 구현하는 데 필요한 노력이 적고 이해하고 사용하기 쉽습니다.

또한 postfix 매크로는 구현하는 데 필요한 노력이 적고 이해하고 사용하기 쉽습니다.

또한 일반적인 lang 기능을 사용하고

postfix 매크로는 postfix의 간결함과 연쇄 성을 비마 법적인 속성 및 명백한 매크로의 존재와 결합하고 일부 .await_debug!() , .await_log!(WARN) 와 같은 타사 사용자 매크로에 잘 맞습니다. .await_trace!()

접미사 매크로는 [...] 매크로의 비마 법적 속성 [...]을 결합하므로 좋을 것입니다.

@novacrazy 이 인수의 문제는 await! 매크로 _would_가 마법이 될 수 있다는 것입니다. 사용자가 작성한 코드에서는 불가능한 작업을 수행하고 있습니다 (현재 기본 생성기 기반 구현이 다소 노출되어 있지만 제 이해는 안정화되기 전에 이것은 완전히 숨겨 질 것입니다 (실제로 현재 상호 작용하려면 rustc -내부 야간 기능을 사용해야합니다)).

@ Nemo157 흠. 나는 그것이 너무 불투명하다는 것을 알지 못했습니다.

마법의 키워드가 아닌 "비동기"함수에서 생성기 함수로 변환하기 위해 #[async] 와 같은 절차 적 매크로를 사용하는 것을 재고하기에는 너무 늦었습니까? 3 개의 추가 문자를 입력해야하며 #[must_use] 또는 #[repr(C)] 와 같은 방식으로 문서에 표시 할 수 있습니다.

나는 실행의 흐름을 직접 제어하는 ​​추상화 레이어를 너무 많이 숨기는 것이 싫다. Rust가 무엇인지에 반대되는 느낌입니다. 사용자는 코드를 완전히 추적하고 모든 것이 어떻게 작동하고 어디에서 실행되는지 파악할 수 있어야합니다. 그들은 사물을 해킹하고 시스템을 속이 도록 장려 해야하며, 안전한 Rust를 사용한다면 안전해야합니다. 우리가 낮은 수준의 통제력을 잃는다면 이것은 아무것도 개선되지 않으며, 나는 원시 선물을 고수하는 것이 좋습니다.

나는 언어 ( std / core 아님) 인 Rust가 사용자 또는 std 가 불가능한 (또는 매우 비현실적인) 경우에만 추상화와 구문을 제공해야한다고 굳게 믿습니다 core . 이 모든 비동기 작업은 그 점에서 손을 떼었습니다. rustc 의 핀 API와 생성기 외에 더 많은 것이 필요합니까?

@novacrazy 나는 일반적으로 감정에 동의하지만 결론에는 동의하지 않습니다.

사용자 나 표준이 수행 할 수없는 (또는 매우 비현실적인) 경우에만 추상화 및 구문을 제공해야합니다.

for 루프가 loop 로 바뀌는 매크로가 될 수도있을 때 언어에서 루프를 갖는 이유는 무엇입니까? || closure 가 전용 트레이 트 및 객체 생성자 일 수있는 이유는 무엇입니까? 이미 try!() 가지고 있는데 왜 ? 도입 했습니까? 내가 그 질문과 당신의 결론에 동의하지 않는 이유는 일관성 때문입니다. 이러한 추상화의 요점은 캡슐화하는 동작뿐만 아니라 그에 대한 접근성입니다. for 대체는 변경 가능성, 기본 코드 경로 및 가독성에서 나뉩니다. || 대체는 선언의 자세한 정도에서 분석됩니다. 현재 Futures 와 유사합니다. try!() 는 예상되는 표현 순서와 조합 가능성으로 분류됩니다.

async 는 함수의 데코레이터 일뿐만 아니라 aync-blocks 및 async || 추가 패턴을 제공하는 다른 생각이 있다는 것을 고려하십시오. 다른 언어 항목에 적용되기 때문에 매크로의 유용성은 차선으로 보입니다. 사용자가 볼 수 있어야하는 경우 구현을 생각하지 마십시오.

사용자는 코드를 완전히 추적하고 모든 것이 어떻게 작동하고 어디에서 실행되는지 파악할 수 있어야합니다. 그들은 사물을 해킹하고 시스템을 속이도록 장려해야하며, 안전한 Rust를 사용한다면 안전해야합니다.

전적으로 std api를 사용하여 코 루틴을 구현하면 unsafe 에 크게 의존 할 가능성이 높기 때문에이 주장이 적용되지 않는다고 생각합니다. 이 상태에서 행할 수 및 당신이-어떤 변화가 만들어 깨는 가정의 위험에 많이 될 것입니다 할 수있는 언어의 구문과 의미 론적 방법이 경우에도 중단되지 않기 때문에 그리고 반대 주장이 unsafe 코드. 나는 Rust가 코 루틴의 내부를 포함하여 곧 안정화 될 의도가없는 비트 구현에 대한 표준 인터페이스를 제공하려는 것처럼 보이게해서는 안된다고 주장합니다. 이것에 대한 유사점은 extern "rust-call" 될 것인데, 이것은 함수 호출이 그러한 보장을 가지고 있지 않다는 것을 분명히하기위한 현재의 마법 역할을합니다. 스택 형 코 루틴의 운명이 아직 결정되지 않았음에도 불구하고 실제로 return 를 원하지 않을 수도 있습니다. 최적화를 컴파일러에 더 깊이 연결하고 싶을 수도 있습니다.

제쳐두고 : 이론 상으로는 완전히 진지한 생각이 아닌 코 루틴이 가상 extern "await-call" fn () -> T 로 표시 될 수 있습니까? 그렇다면 전주곡에서

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

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

일명. 사용자 공간 문서화 항목의 future.await() . 또는 그 문제에 대해 다른 연산자 구문도 가능할 수 있습니다.

안녕하세요.

이미 try!() 가지고 있는데 왜 ? 소개 했습니까?

공정하게 말하면, 나에게도 성장했지만 이에 반대했습니다. Try 이 안정된 경우 더 수용 가능할 것이지만 이는 또 다른 주제입니다.

당신이주는 "설탕"의 예의 문제는 매우 얇은 설탕이라는 것입니다. impl MyStruct 도 impl <anonymous trait> for MyStruct 대해 설탕이 더 많거나 적습니다. 이것들은 간접비를 전혀 추가하지 않는 삶의 질 설탕입니다.

반대로 생성기와 비동기 함수는 전혀 중요하지 않은 오버 헤드와 상당한 정신적 오버 헤드를 추가합니다. 생성기는 특히 사용자로서 구현하기가 매우 어렵고 언어 자체의 일부로 더 효과적이고 쉽게 사용할 수있는 반면 비동기는 상대적으로 쉽게 구현할 수 있습니다.

비동기 블록 또는 클로저에 대한 요점은 흥미롭고 키워드가 더 유용 할 것이라는 점을 인정하지만 필요한 경우 하위 수준 항목에 액세스 할 수 없다는 것에 여전히 반대합니다.

이상적으로는 async 키워드 와 #[async] 속성 / 프로 시저 매크로를 지원하는 것이 좋을 것입니다. 전자는 생성 된 (말장난 의도가없는) 생성기에 대한 저수준 액세스를 허용합니다. 한편 yield 는 키워드로 async 를 사용하는 블록이나 함수에서 허용되지 않아야합니다. 구현 코드를 공유 할 수도 있다고 확신합니다.

에 관해서는 await , 위의 모두가 가능한 경우, 우리는 비슷한 일을하고, 키워드 제한 할 수 await 에 async 키워드 기능 / 블록을, 그리고 어떤 종류를 사용 await!() #[async] 함수의 await!() 매크로.

의사 코드 :

// 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);
}

두 세계의 최고.

이것은 사용자에게 제시 할 복잡성의 자연스러운 진행처럼 느껴지며 더 많은 응용 프로그램에 더 효과적으로 사용할 수 있습니다.

이 문제는 특히 await 구문에 대한 논의를위한 것임을 기억하십시오. async 함수와 블록이 어떻게 구현되는지에 대한 다른 대화는 범위를 벗어났습니다. 단, await! 는 Rust에서 쓸 수 있거나 쓸 수있는 것이 아니라는 것을 사람들에게 상기시키기위한 목적을 제외하고는 예외입니다. 표면 언어.

모든 수정 후 구문 제안의 장단점에 대해 특별히 가중치를 부여하고 싶습니다. 구문 중 하나가 약간의 단점으로 눈에 띈다면, 우리는 그것을 선택해야 할 것입니다. 그러나 아무 것도 없다면, 필요한 경우 아직 결정되지 않은 post-fix와 순방향 호환되는 구문 접두사 구분 구문을 지원하는 것이 가장 좋습니다. Postfix는 일부 회원에게 가장 간결한 것으로 공감하는 것처럼 보이므로 다른 회원으로 이동하기 전에 먼저이를 강력하게 평가하는 것이 실용적입니다.

비교는 syntax , example (@mehcode의 reqwest 는이 점에서 사용할 수있는 실제 벤치 마크처럼 concerns , 선택적 resolution , 예를 들어 교육으로 이어질 수 있다는 데 동의 한 경우). 구문 및 / 또는 우려 사항을 자유롭게 추가해 주시면이 공동 게시물에 편집하겠습니다. 내가 이해하는 바와 같이, await 포함하지 않는 모든 구문은 신규 이민자와 숙련 된 사용자 모두에게 낯설게 느껴지지만 현재 나열된 모든 구문에는이를 포함합니다.

참조 용으로 만 한 접두사 구문의 예입니다.이 부분은 자전거를 타지 마십시오.

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

• 접미사 키워드 foo() await?
  
  
  
  • 예 : client.get("https://my_api").send() await?.json() await?
  
  
  • | 우려 | 해상도 |
    
    |-|-|
    
    | ? 없이 연결하면 혼란 스럽거나 허용되지 않을 수 있습니다. |
  
  
• 접미사 필드 foo().await?
  
  
  
  • 예 : client.get("https://my_api").send().await?.json().await?
  
  
  • | 우려 | 해상도 |
    
    |-|-|
    
    | 필드처럼 보인다 | |
  
  
• 후위 방법 foo().await()?
  
  
  
  • 예 : client.get("https://my_api").send().await()?.json().await()?
  
  
  • | 우려 | 해상도 |
    
    |-|-|
    
    | 방법이나 특성처럼 보인다 | ops:: 특성으로 문서화 될 수 있습니까? |
    
    | 함수 호출이 아님 | |
  
  
• Postfix 통화 foo()(await)?
  
  
  
  • 예 : client.get("https://my_api").send()(await)?.json()(await)?
  
  
  • | 우려 | 해상도 |
    
    |-|-|
    
    | 실제 인수와 혼동 될 수 있음 | 키워드 + 하이라이트 + 겹치지 않음 |
  
  
• 접미사 매크로 foo().await!()?
  
  
  
  • 예 : client.get("https://my_api").send().await!()?.json().await!()?
  
  
  • | 우려 | 해상도 |
    
    |-|-|
    
    | 실제로 매크로가 아닙니다… | |
    
    | … 또는 await 더 이상 키워드가 아님 | |
  
  

생성자를 통합 할 가능성이있는 관점에서 접두사 대 접두사에 대한 추가 생각 : 값 고려, yield 및 await 는 두 가지 상반되는 문 유형을 차지합니다. 전자는 기능에서 외부로 값을주고 후자는 값을받습니다.

참고 : Python에는 yield 가 값을 반환 할 수있는 대화 형 생성기 가 있습니다. 대칭 적으로 이러한 생성기 또는 스트림에 대한 호출에는 강력한 유형 설정에서 추가 인수가 필요합니다. 너무 많이 일반화하려고하지 말자. 그러면 두 경우 모두 인수가 이전 될 가능성이 있음을 알 수 있습니다.

그런 다음 이러한 진술이 닮아 보이도록 만드는 것은 자연스러운 일이라고 주장합니다. 여기에서 할당 표현식과 유사하게, 다른 언어에 의해 설정된 규범이 Rust에 대해 덜 일관성 있고 덜 간결 할 때 우리는 다른 언어에서 설정 한 규범에서 벗어나야합니다. 다른 곳에서 표현했듯이 await 를 포함하고 동일한 인수 순서를 가진 다른 표현과의 유사성이 존재하는 한 다른 모델에서 전환하는 데 큰 방해가되지 않아야합니다.

암묵적 인 것처럼 보이기 때문에.

다른 언어로 async / await를 사용하고 여기에서 옵션을 살펴본 결과, 퓨처 체인을 연결하는 것이 구문 적으로 즐겁다는 사실을 발견하지 못했습니다.

체인이 불가능한 변형이 테이블에 있습니까?

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

나는 이것이 패턴의 일부라는 주장을 할 수 있기 때문에 이와 비슷합니다.

바인딩을 기다리는 문제는 오류 스토리가 좋지 않다는 것입니다.

// 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?;

커뮤니티에서 기다릴 수있는 거의 모든 선물은 오류가 있으며 ? 와 결합되어야한다는 점을 명심해야합니다.

구문 설탕이 정말로 필요한 경우 :

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

await 및 await? 둘 다 키워드로 추가하거나이를 let 로 확장해야합니다 (예 : let? result = 1.divide(0);

러스트 코드에서 체인이 얼마나 자주 사용되는지를 고려할 때, 저는 체인 된 awaits가 독자에게 가능한 한 명확 해지는 것이 중요하다는 데 전적으로 동의합니다. await의 접미사 변형의 경우 :

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

이것은 일반적으로 Rust 코드가 동작 할 것으로 예상하는 것과 비슷하게 동작합니다. 이 컨텍스트에서 await() 가 함수 호출처럼 느껴지지만 표현식 컨텍스트에서 마법 같은 (비 함수와 같은) 동작이 있다는 사실에 문제가 있습니다.

접미사 매크로 버전은 이것을 더 명확하게합니다. 사람들은 "여기에 마법이있다"는 의미의 녹으로 된 느낌표에 익숙하며,이 버전을 선호합니다.

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

즉, 이미 try!(expr) 언어로되어 있고 ? 의 선구자라는 점을 고려할 가치가 있습니다. 이제 await!(expr) 매크로를 추가하면 try!(expr) 및 ? 가 언어에 도입 된 방식과 완전히 일치합니다.

await!(expr) 버전의 await를 사용하면 나중에 접미사 매크로로 마이그레이션하거나 새로운 ? 스타일 연산자를 추가하여 쉽게 연결할 수 있습니다. ? 와 유사하지만 await에 대한 예 :

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

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

await!(expr) 또는 await!{expr} 는 매우 합리적이고 실용적이기 때문에 지금은 사용해야한다고 생각합니다. 그런 다음 나중에 접미사 매크로가 문제가되면 나중에 await의 접미사 버전 (예 : .await! 또는 .await!() )으로 마이그레이션 할 계획을 세울 수 있습니다. (또는 결국 추가 ? 스타일 연산자를 추가하는 경로로 이동합니다 ... 주제에 대해 많은 자전거를 흘린 후 : P)

참고로 Scala의 구문은 차단 호출이므로 Await.result 가 아닙니다 . Scala의 Future는 모나드이므로 일반적인 메서드 호출 또는 for 모나드 이해를 사용합니다.

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

이 끔찍한 표기법의 결과로 다음과 같이 내가 가장 선호하는 구문으로 scala-async 라이브러리가 생성되었습니다.

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
}

이것은 필수 구분 기호를 사용하여 Rust 코드가 원하는 모습을 강력하게 반영하므로 await!() 의 현재 구문을 유지하는 데 다른 사람들과 동의하고 싶습니다. 초기 Rust는 심볼이 무거웠 고, 정당한 이유로 멀어졌습니다. 접미사 연산자 (또는 당신이 가지고있는 것)의 형태로 구문 설탕을 사용하는 것은 언제나처럼 이전 버전과 호환되며 await!(future) 의 명확성은 모호하지 않습니다. 또한 앞서 언급했듯이 try! 진행 한 과정을 반영합니다.

매크로로 유지하는 이점은 일반 함수 호출이 아니라 언어 기능이라는 것이 한눈에 더 분명하게 드러난다는 것입니다. ! 추가하지 않으면 편집기 / 뷰어의 구문 강조 표시가 호출을 찾을 수있는 가장 좋은 방법이 될 것이며 이러한 구현에 의존하는 것이 더 약한 선택이라고 생각합니다.

내 2 센트 (정기 기부자가 아님, fwiw) 저는 try! 모델을 복사하는 데 가장 많은 부분을

그래서 내 투표는 다음과 같습니다 : await!(...) 안정화하고 Rust 개발자의 여론 조사를 기반으로 멋진 체인을 위해 접미사 연산자를 사용합니다. Await는 키워드이지만 ! 는 그것이 나에게 "마법"이라는 것을 나타내며 괄호는 명확하게 유지합니다.

또한 비교 :

| 접미사 | 표현 |
| --- | --- |
| .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()$? |

내 세 번째 센트는 내가 @ ( "await")와 # (멀티 스레딩 / 동시성을 나타냄)를 좋아한다는 것입니다.

나는 @ 접미사도 좋아합니다! 실행 불가능하다는 감정이있는 것 같지만 실제로 나쁜 선택은 아니라고 생각합니다.

• _ @ for await_는 멋지고 기억하기 쉬운 니모닉입니다.
• ? 및 @ 은 (는) 매우 유사하므로 @ 을 (를) 배우고 ? @ 을 (를) 배우는 것이 그렇게 도약해서는 안됩니다.
• 표현식을 이해하기 위해 닫는 구분 기호를 찾기 위해 앞으로 스캔 할 필요없이 왼쪽에서 오른쪽으로 일련의 표현식을 스캔하는 데 도움이됩니다.

나는 await? foo 구문을 매우 선호하며 수학에서 볼 수있는 구문과 비슷하다고 생각합니다. sin² x는 (sin x) ²를 의미하는 데 사용할 수 있습니다. 처음에는 조금 어색해 보이지만 익숙해지기 쉽다고 생각합니다.

위에서 말했듯이 지금은 try!() 처럼 매크로로 await!() 를 추가하고 결국에는 접미사 방식을 결정하는 것이 좋습니다. await!() 호출을 postfix로 자동 변환하는 rustfix에 대한 지원을 염두에두면 아직 결정되지 않은 것이 더 좋습니다.

postfix 키워드 옵션은 저에게 분명한 승자입니다.

• 우선 순위 / 순서 문제는 없지만 괄호로 순서를 명시 할 수 있습니다. 그러나 대부분은 과도한 중첩이 필요하지 않습니다 ( 'try ()!'대신 접미사 '?'를 선호하는 유사한 인수).

• 다중 라인 체인으로보기 좋으며 (@earthengine의 이전 주석 참조) 주문이나 대기중인 항목에 대한 혼동이 없습니다. await를 여러 번 사용하는 표현식에는 중첩 / 추가 괄호가 없습니다.

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

• 간단한 await! () 매크로에 적합합니다 (@novacrazy의 이전 주석 참조).

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

• 한 줄, 네이 키드 ( '?'없이), postfix await 키워드 체인은 왼쪽에서 오른쪽으로 읽고 후속 메소드가 작동하는 값의 반환을 기다리고 있기 때문에 나를 괴롭히지 않습니다. 여러 줄의 rustfmt'ed 코드 선호). 공간은 선을 나누고 대기중인 시각적 표시기 / 큐로 충분합니다.

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

아직 보지 못한 다른 후보를 제안하기 위해 (아마도 파싱 할 수 없기 때문일 것입니다.) 재미있는 이중 점 '..'접미사 연산자는 어떻습니까? 그것은 우리가 무언가를 기다리고 있다는 것을 상기시켜줍니다 (결과!) ...

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

나는 @ 접미사도 좋아합니다! 실행 불가능하다는 감정이있는 것 같지만 실제로 나쁜 선택은 아니라고 생각합니다.

• _ @ for await_는 멋지고 기억하기 쉬운 니모닉입니다.
• ? 및 @ 은 (는) 매우 유사하므로 @ 을 (를) 배우고 ? @ 을 (를) 배우는 것이 그렇게 도약해서는 안됩니다.
• 표현식을 이해하기 위해 닫는 구분 기호를 찾기 위해 앞으로 스캔 할 필요없이 왼쪽에서 오른쪽으로 일련의 표현식을 스캔하는 데 도움이됩니다.

나는 기다릴 때 @를 사용하는 팬이 아닙니다. 오른쪽 엄지 손가락으로 alt-gr을 누른 다음 숫자 행에서 키 2를 눌러야하기 때문에 fin / swe 레이아웃 키보드에 입력하는 것이 어색합니다. 또한 @는 (at) 잘 정립 된 의미를 가지고있어서 왜 그 의미를 혼동해야하는지 모르겠습니다.

저는 단순히 await 를 입력하는 것보다 훨씬 더 빠릅니다. 키보드 곡예가 필요하지 않기 때문에 더 빠릅니다.

여기 내 자신의 매우 주관적인 평가가 있습니다. 또한 future@await 추가했습니다.

| 구문 | 노트 |
| --- | --- |
| await { f } | 강한:

• 매우 간단
• 유사점 for , loop , async 등

• 매우 장황함 (5 개의 문자, 2 개의 중괄호, 3 개의 선택 사항이지만 보풀이있는 공백)
• 연결 결과 많은 중첩 중괄호 ( await { await { foo() }?.bar() }? )

• Python, JS, C # 및 Dart의 await 구문과 유사합니다.
• 간단하고 짧음
• 유용한 우선 순위와 명백한 우선 순위는 모두 ? ( await fut? 대 await? fut )와 잘 작동합니다.

• 모호함 : 유용함 vs. 명백한 우선 순위를 배워야 함
• 체이닝 또한 매우 번거 롭습니다 ( await (await foo()?).bar()? 대 await? (await? foo()).bar() )

• 매우 쉬운 연결을 허용합니다
• 짧은
• 멋진 코드 완성

• 사용자를 속여 어딘가에 정의 된 필드 / 기능 / 매크로라고 생각하게 만듭니다. 편집 : 나는 await!() 가 가장 마법처럼 느껴 지지 않는다는

• 매우 쉬운 연결을 허용합니다
• 짧은

• 사용자가 await 변수가 어딘가에 정의되어 있고 Future가 함수처럼 호출 될 수 있다고 생각하도록 속입니다.

• 매우 쉬운 연결을 허용합니다
• 짧은

• Rust의 구문에서 아무것도 유사하지 않습니다.
• 내 두뇌는 client.get("https://my_api").send() await.unwrap().json() await.unwrap() 를 client.get("https://my_api").send() , await.unwrap().json() 및 await.unwrap() 그룹화합니다 (먼저 별로 그룹화 한 다음 . ) 맞지 않습니다
• Haskellers : 카레처럼 보이지만 그렇지 않습니다.

• 매우 쉬운 연결을 허용합니다
• 매우 짧은

• 약간 어색해 보인다 (적어도 처음에는)
• @ 소비하며 다른 것에 더 적합 할 수 있습니다.
• 특히 큰 표현에서 간과하기 쉬울 수 있습니다.
• 다른 모든 언어와 다른 방식으로 @ 사용

• 매우 쉬운 연결을 허용합니다
• 짧은
• 멋진 코드 완성
• await 은 키워드가 될 필요가 없습니다.
• forwards-compatible : @operator 형식으로 새 접미사 연산자를 추가 할 수 있습니다. 예를 들어 ? 는 @try 로 수행 될 수 있습니다.
• 내 두뇌는 client.get("https://my_api").send()@await.unwrap().json()@await.unwrap() 를 올바른 그룹으로 그룹화합니다 (먼저 . 별로 그룹화 한 다음 @ )

• 다른 모든 언어와 다른 방식으로 @ 사용
• 불필요한 접미사 연산자를 너무 많이 추가 할 수 있습니다.

내 점수 :

• 익숙 함 (fam) :이 구문이 알려진 구문 (Rust 및 Python, JS, C #과 같은 기타)에 얼마나 가까운 지
• 명백 함 (obv) : 처음으로 다른 사람의 코드에서 이것을 읽었다면 의미, 우선 순위 등을 추측 할 수 있습니까?
• 상세도 (vrb) : 쓰는 데 걸리는 문자 수
• 가시성 (vis) : 코드에서 발견하기가 얼마나 쉬운가 (vs. 간과하기)
• chaining (cha) : . 및 기타 await 으로 연결하는 것이 얼마나 쉬운가
• 그룹화 (grp) : 내 두뇌가 코드를 올바른 덩어리로 그룹화하는지 여부
• forwards-compatibility (fwd) : 나중에 중단되지 않는 방식으로 조정할 수 있는지 여부

| 구문 | fam | obv | vrb | 마주 | 차 | 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 |

첫 번째 컷에서 try!() 구문을 미러링하고 다른 구문을 도입하기 전에 await!(expr) 사용을 실제적으로 사용해야하는 것처럼 느껴집니다.

그러나 만약 우리가 대체 구문을 생성한다면 ..

나는 @ 가보기 흉해 보인다고 생각하고, "async"의 "at"는 나에게 그다지 직관적 인 느낌이 들지 않으며, 기호는 이미 패턴 매칭에 사용된다.

괄호가없는 async 접두사는 ? (자주 사용됨)와 함께 사용할 때 명확하지 않은 우선 순위 또는 주변 괄호로 이어집니다.

접미사 .await!() 체인은 멋지게, 그 의미가 매우 분명하게 느껴지며, 마법을 할 것이라는 것을 알려주는 ! 가 포함되어 있으며, 구문 적으로 덜 새롭습니다. 개인적으로 이것을 선호 할 것입니다. 즉, 첫 번째 컷 await! (expr) 보다 실제 코드를 얼마나 향상시킬 수 있는지는 아직 알 수 없습니다.

간단한 경우에는 접두사 연산자를 선호합니다.
let result = await task;
결과 유형을 작성하지 않는다는 점을 고려하는 것이 훨씬 더 자연 스럽기 때문에 await는 결과가 기다리는 작업이라는 것을 이해하기 위해 왼쪽에서 오른쪽으로 읽을 때 정신적으로 도움이됩니다.
다음과 같이 상상해보십시오.
let result = somehowkindoflongtask await;
작업의 끝에 도달하지 않을 때까지 반환되는 유형을 기다려야한다는 것을 인식하지 못합니다. Intellij로서의 IDE는 이름과 같음 사이에 유형 (가능한 경우 개인화없이)을 인라인한다는 점을 염두에 두십시오 (이는 변경 될 수 있으며 언어의 미래와 직접 연결되지는 않음).
다음과 같이 상상해보십시오.

그렇다고 내 의견이 접두사에 대해 100 %라는 의미는 아닙니다. 결과가 포함될 때 미래의 접미사 버전을 매우 선호합니다. 문맥이 없어도 다음 중 어떤 것이 무엇을 의미하는지 쉽게 알 수 있습니다.
future await?
future? await
대신 초보자의 관점에서이 두 가지 중 어느 것이 사실인지 살펴보십시오.
await future? === await (future?)
await future? === (await future)?

나는 접두사 키워드 await future 를 선호합니다.

비동기 / 대기 기능이있는 대부분의 프로그래밍 언어에서 사용하는 언어이므로 그중 하나를 아는 사람들에게 즉시 익숙합니다.

await future? 의 우선 순위에 대해 일반적인 경우는 무엇입니까?

• 기다려야하는 Result<Future> 를 반환하는 함수.
• Result : Future<Result> 를 반환하는 기다려야하는 미래.

두 번째 경우는 I / O 작업이 실패 할 수 있으므로 일반적인 시나리오를 처리 할 때 훨씬 더 일반적이라고 생각합니다. 따라서:

await future? <=> (await future)?

덜 일반적인 첫 번째 경우에는 await (future?) 괄호를 사용할 수 있습니다. 이것은 심지어위한 좋은 사용 될 수 try! :이 사용되지 않았다면 매크로 await try!(future) . 이렇게하면 await 와 물음표 연산자가 미래의 다른 측면에 있지 않습니다.

await 를 첫 번째 async 함수 매개 변수로 사용하지 않는 이유는 무엇입니까?

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);

여기서 future.run(await) 는 await future 있습니다.
미래를 취하고 단순히 await!() 매크로를 실행하는 일반 async 함수일 수 있습니다.

C ++ (동시성 TR)

auto result = co_await task;

이것은 동시성이 아닌 코 루틴 TS에 있습니다.

다른 옵션은 await 대신 become 키워드를 사용할 수 있습니다.

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 는 보장 된 TCO의 키워드가 될 수 있습니다.

[개요]에 대해 @EyeOfPython 에게 감사드립니다. 이것은 지금 막 자전거 창고에 합류하는 사람들에게 특히 유용합니다.

개인적으로 나는 우리가 f await 에서 멀리 떨어져 있기를 바랍니다. 왜냐하면 매우 소박한 구문이 현명하고 좀 특별하고 마법처럼 보이기 때문입니다. Rust를 처음 접하는 사용자들이 많이 혼란스러워하는 것은 이러한 것들 중 하나가 될 것이며, Rust 베테랑들에게도 그만한 가치가 있다고 생각합니다.

@novacrazy 이 인수의 문제는 await! 매크로 _would_는 마법이 될 수 있으며 사용자가 작성한 코드에서는 불가능한 작업을 수행한다는 것입니다.

@ Nemo157 await! 매크로가 마법이라는 데 동의하지만 이것이 문제가되지 않는다고 주장합니다. std 이미 compile_error! 와 같은 여러 매크로가 있으며 이에 대해 불평하는 사람을 본 적이 없습니다. 매크로를 사용하는 것은 그것이하는 일이 아니라 그것이하는 일만 이해하는 것이 정상이라고 생각합니다.

나는 후위 가장 인체 공학적 될 것이라고 이전 덧글에 동의하지만, 차라리 접두사 매크로로 시작 것 await!(expr) 그 일이되면 접미사 매크로 잠재적 및 전환보다는이 expr.await (매직 컴파일러 내장 필드) 또는 expr.await() (매직 컴파일러 내장 메서드). 둘 다 순수하게이 기능을위한 완전히 새로운 구문과 언어가 일관성이 없다고 느끼게하는 IMO를 도입합니다.

@EyeOfPython 목록과 테이블에 future(await) 을 (를) 추가 하시겠습니까? future.await() 에 대한 평가의 모든 긍정적 인 점이 약점없이 이전되는 것 같습니다.

일부는 구문 강조에도 불구하고 foo.await 가 필드 액세스와 너무 비슷해 보인다고 주장했기 때문에 . 토큰을 # 하고 대신 foo#await 를 작성할 수 있습니다. . 예를 들면 :

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

GitHub가 구문 강조 표시를 사용하여이를 렌더링하는 방법을 설명하기 위해 await 를 match 대체합니다.

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

이것은 명확하고 인체 공학적으로 보입니다.

다른 토큰보다 # 의 이론적 근거는 구체적이지 않지만 토큰은 눈에 잘 띄어 도움이됩니다.

그래서, 또 다른 개념 : 만약 미래가 참조라면 :

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;

이것은 정말 추하고 일관성이 없을 것입니다. 적어도 그 구문을 명확하게 해보자 :

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;

더 좋지만 여전히 못 생겼습니다 (그러나 더 나빠지면 github의 구문 강조 표시가됩니다). 그러나이를 처리하기 위해 접두사 연산자 를

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;

이것이 내가 원하는 것입니다! await ( $ )뿐만 아니라 deref ( * ) 및 부정 ( ! )도 마찬가지입니다.

이 구문의 몇 가지주의 사항 :

1. 연산자 우선 순위 : 나에게는 분명하지만 다른 사용자에게는 분명합니까?
2. 매크로 interop : $ 기호가 여기서 문제를 일으킬까요?
3. 식 불일치 : 선행 접두사 연산자는 전체 식에 적용되는 반면 지연 접두사 연산자는 . 구분 된 식에만 적용됩니다 ( await_chain fn은이를 보여줍니다). 혼란 스럽습니까?
4. 구문 분석 및 구현 : 해당 구문이 전혀 유효합니까?

센트릴
IMO #가 원시 리터럴 구문 r#"A String with "quotes""# 너무 가깝습니다.

IMO #가 원시 리터럴 구문 r#"A String with "quotes""# 너무 가깝습니다.

이 경우 차이점이 무엇인지 문맥 상 아주 분명해 보입니다.

센트릴
하지만 구문은 Rust가 IMHO를 사용하는 스타일과는 전혀 다릅니다. 유사한 기능을 가진 기존 구문과 유사하지 않습니다.

@Laaas 소개되었을 때 ? 도하지 않았습니다. 나는 .await 와 함께 기꺼이 할 것입니다; 나는 (체인 가능, 좋은 우선 순위가 충분히 쉽게 입력, 즉, 분명 인체 공학적입니다) 작품 것을 다른 뭔가를 찾기 위해 노력하고 있고, 그래서하지만 다른 사람들은 불만 보인다 foo#await 이 모든 것을 만족시킬 것으로 보인다.

? 에는 다른 좋은 점이 많이 있지만 #await는 다소 임의적으로 보입니다. 어쨌든 .await 와 같은 것을 원한다면 .await! 어떻습니까?

@Centril 이것이 future(await) 이면의 주된 근거로, 추가 연산자 나 외부 구문을 추가하지 않고도 필드 액세스를 피할 수 있습니다.

#await는 다소 임의적 인 것처럼 보입니다.

# 은 임의적입니다. 그렇습니다. 어떤 시점에서 새로운 구문이 발명 될 때 누군가 그것이 좋게 보이거나 합리적이라고 생각했기 때문에 그것은 임의적이어야합니다.

왜 .await! ?

그것은 똑같이 임의적이지만 나는 그것에 반대하지 않습니다.

@Centril 이것이 future(await) 이면의 주된 근거 였는데, 추가 연산자 나 외부 구문을 추가 할 필요없이 필드 액세스를 방지하기위한 것입니다.

대신 await 를 future 전달하는 함수 응용 프로그램처럼 보입니다. "현장 접근"보다 더 혼란 스러워요.

대신 당신이 미래를 기다리고있는 함수 애플리케이션처럼 보입니다. "현장 접근"보다 더 혼란 스러워요.

나에게 그것은 간결함의 일부였습니다. Await는 함수 호출과 같은 여러 측면에 있으며 (callee는 사용자와 결과 사이에서 실행 됨) 해당 함수에 키워드를 전달하면 이것이 다른 종류의 호출임을 분명히 알 수 있습니다. 그러나 키워드가 다른 인수와 유사하다는 것이 얼마나 혼란 스러울 수 있는지 봅니다. (마이너스 구문 강조 표시 및 해당 메시지를 강화하려는 컴파일러 오류 메시지. Futures는 대기하는 것 외에 다른 방법으로 호출 할 수 없으며 그 반대도 마찬가지입니다.)

센트릴

임의적 인 것은 제외 것은 아니지만, 기존 구문 유사성을 갖는 양의 물건이다. .await! 은 완전히 새로운 구문이 아니기 때문에 임의적이지 않습니다. 결국 await 라는 후위 매크로 일뿐입니다.

특히 await 에 대한 새 구문에 대한 요점을 명확히 / 추가하기 위해 기존 구문과 다른 새로운 구문을 도입한다는 의미입니다. 많은 접두사 키워드가 있으며, 그중 일부는 Rust 1.0 이후에 추가되었지만 (예 : union ) AFAIK는 단일 접미사 키워드가 아닙니다 (공백, 점 또는 다른 것으로 구분 되더라도 상관 없음) . 접미사 키워드가있는 다른 언어도 생각할 수 없습니다.

IMHO는 Rust의 이상 함을 크게 증가시키지 않는 유일한 접미사 구문은 postfix 매크로입니다. 왜냐하면 메서드 호출을 미러링하기 때문이지만 이전에 Rust 매크로를 본 사람이라면 누구나 매크로로 명확하게 식별 할 수 있기 때문입니다.

나는 또한 표준 await!() 매크로를 좋아했습니다. 명확하고 간단합니다.
나는 awaited 같이 공존하기 위해 필드와 같은 액세스 (또는 다른 접미사)를 선호합니다.

• Await는 당신이 다음 / 올바른 일을 기다리고있을 것이라고 느낍니다. 기다림, 이전 / 왼쪽에 온 것.
• 반복기의 cloned() 메서드와 일치합니다.

그리고 @? 도 ? 같은 설탕으로 좋아했습니다.
이것은 개인적이지만 실제로는 &? 조합을 선호합니다. @ 는 너무 길고 선을 너무 산만하게 만드는 경향이 있기 때문입니다. & 도 키가 크지 만 (좋음) 미달하지 않습니다 (또한 좋습니다). 안타깝게도 & 에는 이미 의미가 있지만 항상 ? 뒤에 올 것입니다.

예 :

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

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

나에게 @ 는 부풀어 오른 캐릭터처럼 느껴지고 읽기 흐름이 산만 해집니다. 반면에 &? 는 기분이 좋고 (내) 독서를 방해하지 않으며 & 와 ? 사이에 멋진 공간이 있습니다.

개인적으로 간단한 await! 매크로를 사용해야한다고 생각합니다. post-fix 매크로가 언어에 들어가면 매크로는 단순히 확장 될 수 있습니다.

@Laaas 내가 원하는만큼 Rust에는 아직 postfix 매크로가 없으므로 새로운 구문입니다. 또한 foo.await!.bar 및 foo.await!().bar 는 동일한 표면 구문이 아닙니다. 후자의 경우 실제 접미사 및 내장 매크로가있을 것입니다 (키워드로 await 를 포기해야 함).

@jplatte

많은 접두사 키워드가 있으며, 그중 일부는 Rust 1.0 이후에 추가되었습니다 (예 : union ).

union 은 단항 표현식 연산자가 아니므로이 비교와 관련이 없습니다. Rust에는 정확히 3 개의 안정된 단항 접두사 연산자 ( return , break , continue )가 있으며 모두 ! 됩니다.

흠 ... @ 사용하면 이전 제안 이 약간 더 좋아 보입니다.

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 그것이 제 요점입니다. 아직 수정 후 매크로가 없기 때문에 await!() 이어야합니다. 또한 나는 .await!() FYI를 의미했습니다. await 가 키워드가 될 필요는 없다고 생각하지만 문제가있는 경우 예약 할 수 있습니다.

union 은 단항 표현식 연산자가 아니므로이 비교에서 관련이 없습니다. Rust에는 정확히 3 개의 안정된 단항 접두사 연산자 ( return , break , continue )가 있으며 모두 ! 됩니다.

이것은 프리픽스-키워드 변형이 다르게 입력하더라도 단항 표현식 연산자 그룹에 적합 함을 의미합니다. postfix-keyword 변형은 기존 구문에서 훨씬 더 큰 차이이며, 제 생각에는 언어에서 await 의 중요성과 관련하여 너무 큽니다.

접두사 매크로 및 사후 수정으로 전환 가능성 : await 이 작동하려면 키워드로 남아 있어야합니다. 매크로는 추가 r# 없이 키워드를 이름으로 사용할 수있는 특별한 lang 항목이되고 r#await!() 는 동일한 매크로를 호출 할 수는 있지만 호출해서는 안됩니다. 그 외에는 사용 가능하게 만드는 가장 실용적인 솔루션처럼 보입니다.

즉, await 를 키워드로 유지하고 await! 를 lang-item 매크로로 확인합니다.

@HeroicKatora 작동하려면 키워드로 남아 있어야하는 이유는 무엇입니까?

@Laaas 왜냐하면 우리가 전환 가능성을 열어두고 싶다면 그것을 키워드로 사용하는 향후 수정 후 구문을 위해 열려 있어야하기 때문입니다. 따라서 전환을 위해 에디션 중단이 필요하지 않도록 키워드 예약을 유지해야합니다.

센트릴

또한 foo.await! .bar 및 foo.await! (). bar는 동일한 표면 구문이 아닙니다. 후자의 경우 실제 접미사 및 내장 매크로 (키워드로 await를 포기해야 함)가 있습니다.

! 와 결합 된 키워드 await 를 내부 매크로 (정상적인 방법으로는 정의 할 수 없음)로 확인하여 해결할 수 없습니까? 그런 다음 키워드로 남아 있지만 그렇지 않은 경우 매크로 구문의 매크로로 확인됩니다.

@HeroicKatora x.await!() await 이 예약 키워드 인 이유는 무엇입니까?

그렇지 않을 수도 있지만 사후 수정을 미해결 상태로 유지하는 경우 이후 논의에서 도달 할 솔루션이 될 필요는 없습니다. 그것이 최선의 가능성에 대해 합의 된 유일한 것이라면, 우리는 우선이 정확한 post-fix 구문을 채택해야합니다.

이것은 우리가 접미사 연산자로서 훨씬 더 잘 작동하는 것을 발견하는 또 다른 시간입니다. 이것의 큰 예는 try! 이며 결국 자체 기호 ? . 그러나 나는 이것이 후위 연산자가 더 최적의 마지막 시간이 아니라고 생각합니다. 그리고 우리는 모든 것에 특별한 문자를 줄 수는 없습니다. 그래서 적어도 @ 시작해서는 안된다고 생각합니다. 이런 일을 할 수있는 방법이 있다면 훨씬 더 좋을 것입니다. 이것이 제가 접미사 매크로 스타일 .await!() 지원하는 이유입니다.

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

그러나 이것이 의미있는 접미사 매크로를 이해하려면 자체적으로 도입되어야합니다. 따라서 일반적인 await!(foo) 매크로 구문으로 시작하는 것이 가장 좋습니다. 나중에 이것을 foo.await!() 또는 foo@ 할 수 있습니다. 이것이 자체 기호를 보증 할만큼 충분히 중요하다고 생각되면.
이 매크로에 약간의 마법이 필요하다는 것은 std에 새로운 것이 아니며 나에게 큰 문제가 아닙니다.
@jplatte가 말했듯이 :

@ Nemo157 await! 매크로가 마술이라는 데 동의하지만 이것이 문제가되지 않는다고 주장합니다. std 이미 여러 매크로가 있습니다. 예를 들어 compile_error! 에 대해 불평하는 사람을 본 적이 없습니다. 매크로를 사용하는 것은 그것이하는 일이 아니라 그것이하는 일만 이해하는 것이 정상이라고 생각합니다.

여기서 논의되는 반복되는 문제는 연결 및 사용 방법에 관한 것입니다.
연결 식에서 기다립니다. 다른 해결책이있을 수 있습니까?

연결에 await를 사용하지 않고 await for 만 사용하려면
우리는 let을 await로 바꾸는 것과 같은 것을 가질 수 있습니다.
await foo = future

그런 다음 연결을 위해 await res = fut1 -> fut2 또는 await res = fut1 >>= fut2 와 같은 일종의 작업을 상상할 수 있습니다.

누락 된 유일한 경우는 대기하고 결과를 반환하는 것입니다.
await res = fut; res .
이것은 평범한 await fut 로 쉽게 할 수 있습니다.

나는 이와 같은 다른 제안을 본 적이 없다고 생각합니다 (적어도
체이닝), 사용하는 것이 좋을 것이라고 생각하는대로 여기에 드롭합니다.

@HeroicKatora 목록에 fut(await) 를 추가하고 내 의견에 따라 순위를 매겼습니다.

누군가 내 점수가 꺼져 있다고 느끼면 알려주세요!

구문 측면에서 .await!() 은 깨끗하고 구문에 이상한 점을 추가하지 않으면 서 체인을 허용한다고 생각합니다.

그러나 "실제"접미사 매크로를 얻으면 약간 이상 할 것입니다. 아마도 .r#await!() 는 섀도 잉 될 수 있지만 .await!() 는 섀도 잉 할 수 없기 때문입니다.

나는 await 가 표현식의 다음 부분에 결합된다는 사실을 발견하기 때문에 "postfix keyword"옵션 ( foo() await?.bar() await? 와 같이 공백으로 구분)에 매우 강력하게 반대합니다. 작동하는 부분이 아닙니다. 여기서는 공백이 아닌 다른 기호를 선호하고 긴 체인의 단점에도 불구하고 접두사 구문을 선호합니다.

필자는 "명백한 우선 순위"( await? 설탕 포함)가 가장 좋은 접두사 옵션이라고 생각합니다. 필수 구분 기호는 단일 문을 기다리는 매우 일반적인 경우에 고통스럽고 "유용한 우선 순위"는 전혀 없기 때문입니다. 직관적이고 따라서 혼란 스럽습니다.

구문 측면에서 .await!() 은 깨끗하고 구문에 이상한 점을 추가하지 않으면 서 체인을 허용한다고 생각합니다.

그러나 "실제"접미사 매크로를 얻으면 약간 이상 할 것입니다. 아마도 .r#await!() 는 섀도 잉 될 수 있지만 .await!() 는 섀도 잉 할 수 없기 때문입니다.

접미사 매크로를 얻고 .await!() 를 사용하면 await 를 키워드로 예약 해제하고 접미사 매크로로 만들 수 있습니다. 이 매크로의 구현에는 여전히 약간의 마법이 필요하지만 오늘날의 compiler_error! 와 같은 실제 매크로가됩니다.

@EyeOfPython forward-compatibility 에서 고려하는 변경 사항을 자세히 설명해 주시겠습니까? fut@await 이 fut.await!() 보다 높고 await { future } 가 await!(future) 보다 낮은 평가를 받는지 잘 모르겠습니다. verbosity 열도 약간 이상해 보이며, 일부 표현은 짧지 만 등급이 낮고, 연쇄 된 문장을 고려합니까? 기타 모든 것은 균형 잡힌 것처럼 보이며 지금까지 가장 잘 요약 된 광범위한 평가와 같습니다.

이 토론을 읽은 후 많은 사람들이 일반적인 await!() 매크로를 추가하고 나중에 접미사 버전을 파악하고 싶어하는 것 같습니다. 그것은 우리가 실제로 postfix 버전을 원한다고 가정하고,이 주석의 나머지 부분에 대해 사실로 간주 할 것입니다.

그래서 저는 여기에있는 모든 사람들의 의견을 조사하고 싶습니다. 우리 모두가 지금 await!(future) 구문에 동의해야합니까? 장점은 해당 구문에 대한 구문 분석 모호성이 없으며 매크로이기도하므로이 변경을 지원하기 위해 언어 구문을 변경하지 않는다는 것입니다. 단점은 체이닝이보기 흉해 보이지만이 구문은 자동으로 후위 버전으로 쉽게 대체 될 수 있기 때문에 중요하지 않습니다.

일단 우리가 그것을 해결하고 그것을 언어로 구현하면, 우리는 더 성숙한 경험, 아이디어 및 아마도 다른 컴파일러 기능으로 postfix await 구문에 대한 토론을 계속할 수 있습니다.

@HeroicKatora await 를 일반 식별자로 자연스럽게 사용할 수 있고 다른 접미사 연산자를 추가 할 수 있다는 점에서 더 높은 평가를 받았지만 fut.await!() 가 await 이면 더 좋을 것이라고 생각합니다. fut.await!() 가 더 높을 수 있다는 것도 확실히 타당 해 보입니다.

await { future } 대 await!(future) 경우, 후자는 옵션을 열어 거의 모든 다른 옵션으로 변경하는 반면, 첫 번째 옵션은 실제로 await future 변형 중 하나만 허용합니다 ( @withoutboats '블로그 항목에 fwd(await { future }) < fwd(await!(future)) 이어야한다고 생각합니다.

자세한 내용은 케이스를 하위 그룹으로 분할 한 후 가장 객관적인 항목이어야하는 자세한 내용을 다시 평가하지 않았습니다.

귀하의 의견을 고려하여 편집하겠습니다. 감사합니다!

await!(future) 안정화는 제가 상상할 수있는 최악의 옵션에 대한 것입니다.

1. 이는 우리가 await 예약을 해제해야한다는 것을 의미하며, 이는 향후 언어 디자인이 더 어려워 짐을 의미합니다.
2. 의도적으로 우리가 더 이상 사용하지 않는 try!(result) 와 동일한 경로를 사용하고 있습니다 (Rust 2018에서 r#try!(result) 를 작성해야 함).
   
   
   
   • await!(future) 가 잘못된 구문이라는 것을 안다면 결국 폐기를 의미하는 것이며 이는 의도적으로 기술적 부채를 창출하는 것입니다.
   
   
   • 게다가 try!(..) 는 Rust에 정의되어 있지만 await!(future) 는 컴파일러 마법이 될 수없고 대신에 그렇게 될 것입니다.
   
   
   • try!(..) 중단은 쉽지 않았고 사회적으로 큰 타격을 입었습니다. 그 시련을 다시 겪는 것은 매력적이지 않습니다.
   
   
3. 이것은 언어의 중심적이고 중요한 부분에 대해 매크로 구문을 사용합니다. 분명히 일류가 아닌 것 같습니다.
4. await!(future) 은 시끄 럽습니다 . 달리 await future 당신은 쓸 필요가 !( ... ) .
5. Rust API, 특히 표준 라이브러리는 메서드 호출 구문을 중심으로합니다. 예를 들어, Iterator 처리 할 때 메서드를 연결하는 것이 일반적입니다. await { future } 및 await future await { future } 와 유사하게 await!(future) 구문은 메서드 체인을 어렵게 만들고 임시 let 바인딩을 유도합니다. 이것은 인체 공학과 가독성에있어서 나쁘다.

@Centril 동의하고 싶지만 몇 가지 열린 질문이 있습니다. 1. 에 대해 확신하십니까? 우리가 그것을 '마법'으로 만든다면 이것을 키워드로 드롭하지 않고 매크로를 참조하도록 허용함으로써 더 마법을 만들 수 없을까요?

나는 2. 의 사회적 관점을 평가하기에는 너무 늦게 Rust에 가입했습니다. 실수를 반복하면 호소 소리가 나지 않는다하지만 여전히 변환되지 않은 일부 코드로 try! 해결책이라고 분명해야한다. 즉 가지고 우리가 의도 여부의 문제가 나타납니다 async/await 인센티브 에디션으로 마이그레이션으로 2018 또는 오히려 일 환자와이를 반복하지합니다.

3. : vec![] 및 format! / println! 와 매우 유사한 두 개의 다른 (imho) 중심 기능. 전자는 안정적인 boxed 구성 afaik이 없기 때문에 매우 많이, 후자는 형식 문자열 구성으로 인해 종속적으로 형식화 된 표현식이 없기 때문입니다. 나는 이러한 비교가 부분적으로 4. 를 다른 관점에 넣었다고 생각합니다.

나는 영어처럼 읽히지 않는 구문에 반대합니다. IE, "await x"는 영어처럼 읽습니다. "x # !! @! &"는 그렇지 않습니다. "x.await"는 영어처럼 감질 나게 읽지 만 x가 긴 이름을 가진 멤버 함수 호출이나 체인 된 반복기 메서드와 같이 사소한 줄이 아닌 경우에는 그렇지 않습니다.

좀 더 구체적으로 말하자면 키워드가 await "키워드 x"를 지원합니다. 저는 C ++ 코 루틴 TS와 유니티의 C # 코 루틴을 모두 사용하여 왔는데, 둘 다 이와 매우 유사한 구문을 사용합니다. 그리고 몇 년 동안 프로덕션 코드에서 사용한 후에는 수익률 포인트가 한 눈에 어디에 있는지 합니다 . 함수의 경우 들여 쓰기 줄을 훑어 볼 때인지 부하없이 몇 초 yield return 에 200 줄 함수에서 co_await / yield return 를 선택할 수 있습니다.

await를 사용하는 도트 연산자 나 다른 접미사 "기호 더미"구문의 경우에도 마찬가지입니다.

나는 await 이 제어 흐름 작업의 기본이라고 생각합니다. 'if , while , match , return 와 동일한 수준의 존중을 받아야합니다. 그것들 중 어느 것이 접미사 연산자라면-Rust 코드를 읽는 것은 악몽이 될 것입니다. await에 대한 제 주장과 마찬가지로 Rust 함수의 들여 쓰기 줄을 훑어보고 즉시 모든 제어 흐름을 선택할 수 있습니다. 예외가 있지만 예외이며 우리가 노력해야 할 것이 아닙니다.

@ejmahler에 동의합니다. 개발의 다른 측면 인 코드 리뷰를 잊지 말아야합니다. 소스 코드가있는 파일은 훨씬 더 자주 읽혀지고 작성되므로, 읽고 이해하는 것이 더 쉬울 것입니다. 항복점을 찾는 것은 코드 검토에서 정말 중요합니다. 그리고 저는 개인적으로 Useful precedence 투표합니다.
나는 이것을 믿는다 :

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

이해하기가 더 쉽습니다.

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

안녕하세요.

@Centril 동의하고 싶지만 몇 가지 열린 질문이 있습니다. 1. 에 대해 확신하십니까? 우리가 그것을 '마법'으로 만든다면 이것을 키워드로 드롭하지 않고 매크로를 참조하도록 허용함으로써 더 마법을 만들 수 없을까요?

기술적으로? 혹시. 그러나 특별한 경우에는 강력한 정당성이 있어야하며이 경우 마법에 마법을 부여하는 것은 정당화되지 않는 것 같습니다.

즉 가지고 우리가 의도 여부의 문제가 나타납니다 async/await 인센티브 에디션으로 마이그레이션으로 2018 또는 오히려 일 환자와이를 반복하지합니다.

우리가 새로운 모듈 시스템 인 async / await 및 try { .. } 를 인센티브로 의도했다고 말한 적이 있는지 모르겠습니다. 하지만 우리의 의도와 상관없이 그들은 좋은 일이라고 생각합니다. 우리는 사람들이 결국 새로운 언어 기능을 사용하여 더 나은 관용적 라이브러리를 작성하기를 원합니다.

3. : vec![] 및 format! / println! 와 매우 유사한 두 개의 다른 (imho) 중심 기능. 전자는 안정된 박스형 구조가 없기 때문에 아파 익,

전자가 존재하며 vec![1, 2, 3, ..] 로 작성되어 배열 리터럴 표현식을 모방합니다 (예 : [1, 2, 3, ..] .

헉헉

"x.await"는 영어처럼 감질 나게 읽지 만 x가 긴 이름을 가진 멤버 함수 호출이나 체인 된 반복기 메서드와 같이 사소한 줄이 아닌 경우에는 그렇지 않습니다.

체인 된 반복기 메소드의 문제점은 무엇입니까? 그것은 분명히 관용적 인 Rust입니다.
rustfmt 도구는 다른 줄에 메서드 체인을 형식화하므로 다음과 같은 결과를 얻을 수 있습니다 (다시 match 를 사용하여 구문 강조 표시를 표시 함).

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

.await 를 "then await"로 읽으면 적어도 나에게는 완벽하게 읽힌다.

그리고 몇 년 동안 프로덕션 코드에서 사용한 후에는 수익률 포인트가 한 눈에 어디에 있는지 합니다 .

나는 특히 위의 rustfmt 형식에서 접미사 await 가 어떻게 그것을 부정하는지 알지 못합니다. 또한 다음과 같이 작성할 수 있습니다.

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();

당신이 그것을 좋아한다면.

인지 부하없이 단 몇 초 만에 200 줄 기능을 수행합니다.

특정 기능에 대해 너무 많이 알지 못하면 200 LOC가 단일 책임 원칙을 위반하고 너무 많은 일을하는 것 같습니다. 해결책은 더 적은 작업을 수행하고 분할하는 것입니다. 사실, 그것이 유지 보수성과 가독성을 위해 가장 중요한 것이라고 생각합니다.

나는 await 이 제어 흐름 작업의 기본이라고 생각합니다.

? 마찬가지입니다. 실제로 await 및 ? 는 모두 "컨텍스트에서 값 추출"이라고 말하는 효과적인 제어 흐름 작업입니다. 즉, 로컬 컨텍스트에서 await : impl Future<Output = T> -> T 및 ? : impl Try<Ok = T> -> T 유형을 갖는 이러한 연산자를 상상할 수 있습니다.

예외가 있지만 예외이며 우리가 노력해야 할 것이 아닙니다.

여기서 예외는 ? ?

안녕하세요.

@ejmahler에 동의합니다. 개발의 다른 측면 인 코드 리뷰를 잊지 말아야합니다. 소스 코드가있는 파일은 훨씬 더 자주 읽혀지고 작성되므로, 읽고 이해하는 것이 더 쉬울 것입니다.

불일치는 가독성과 인체 공학에 가장 적합한 것에 관한 것입니다.

이해하기가 더 쉽습니다.

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

이것은 형식화 방법이 아닙니다. rustfmt 통해 실행하면 다음과 같은 이점이 있습니다.

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

@ejmahler @andreytkachenko 여기서 @Centril에 동의합니다. 접두사 구문에서 얻을 수있는 가장 큰 변화 (일부는 개선이라고 말할 수 있지만 그렇지 않습니다)는 다른 모든 내용을 읽을 수 없기 때문에 사용자가 여러 줄로 문장을 분할하도록 인센티브를 await 는 실제로 양보하는 코드 포인트에 배치되지 않고 오히려 반대되기 때문에 접두사 구문에서 yield-point가 더 모호하다고 생각합니다.

이 방법을 사용하면 @Keruspe 의 아이디어를 실제로 적용하려는 정신에 따라 await 대신 let 대신 철자를 사용하여 철자를 실험 해 봅시다. 스트레치처럼 보이기 때문에 다른 구문 확장이 없습니다.

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

그러나 이것들 중 어느 것도 문법에서 작곡 가능성 손실과 합병증을 설명하기에 충분한 이점을 보지 못했습니다.

흠 ... await의 접두사와 접미사 형식을 모두 갖는 것이 바람직합니까? 아니면 그냥 접미사 형태?

메서드 호출을 함께 연결하는 것은 특히 다음과 같이 말할 때 관용적입니다.
반복자 및 훨씬 적은 범위의 옵션이지만 그 외에는 녹이
명령형 언어가 먼저이고 기능적 언어가 두 번째입니다.

나는 접미사가 말 그대로 이해할 수 없다고 주장하는 것이 아닙니다.
최상위 제어 흐름 작업을 숨기는인지 부하 인수,
'반환'과 동일한 중요성을 지니 며
줄의 시작 부분에 가깝게 두는 것과 비교하면
수년간의 생산 경험을 바탕으로이 주장을합니다.

2019 년 1 월 19 일 토요일 오전 11:59 Mazdak Farrokhzad [email protected]
썼다 :

@HeroicKatora https://github.com/HeroicKatora

@Centril https://github.com/Centril 동의하고 싶지만
몇 가지 공개 질문. 1에 대해 확신합니까? 우리가 그것을 '마법'으로 만든다면
우리는 이것이없이 매크로를 참조하도록 허용함으로써 더 마술을 만들지 않습니다.
키워드로 삭제 하시겠습니까?

기술적으로? 혹시. 그러나 다음에 대한 강력한 정당성이 있어야합니다.
특별한 경우와이 경우 마법에 마법이있는 것 같지 않습니다
정당화.

그것은 우리가 async / await를 가질 것인지에 대한 질문을 제기합니다.
2018 년판으로 마이그레이션하거나 인내심을 가지려는 인센티브
이것을 반복하십시오.

우리가 새로운 모듈 시스템 인 async /를 의도했다고 말했는지 모르겠습니다.
기다렸다가 인센티브로 {..} 시도하십시오. 하지만 우리의 의도와 상관없이
그렇습니다. 좋은 일이라고 생각합니다. 우리는 사람들이 결국
새로운 언어 기능을 사용하여 더 좋고 관용적으로 쓰기 시작
도서관.

3과 매우 유사한 두 개의 다른 (imho) 중심 기능 : vec! [] 및 format! /
println !. 갑은 안정된 박스가 없기 때문에 매우
건설 afaik,

전자가 존재하고 배열을 모방하기 위해 vec! [1, 2, 3, ..]로 작성되었습니다.
리터럴 표현식, 예 : [1, 2, 3, ..].

@ejmahler https://github.com/ejmahler

"x.await"는 영어처럼 감질 나게 읽지 만 x가 a 일 때는 그렇지 않습니다.
긴 이름을 가진 멤버 함수 호출 또는 무리와 같은 사소하지 않은 줄
체인 반복기 메서드 등

체인 된 반복기 메소드의 문제점은 무엇입니까? 그것은 분명히
관용적 녹.
rustfmt 도구는 또한 다른 줄에 메소드 체인을 포맷하여
get (다시 일치를 사용하여 구문 강조 표시) :

let foo = alpha (). match? // 또는 alpha() match? , alpha()#match? , alpha().match!()?
.베타
.some_other_stuff (). match?
.even_more_stuff (). match
.stuff_and_stuff ();

.await를 "then await"로 읽으면 적어도 나에게는 완벽하게 읽힌다.

그리고 생산 코드에 그들을 사용의 년 후에, 나의 믿음은 그 알고있다한눈에 수익률 포인트가있는 곳은 절대적으로 중요 합니다.

나는 postfix가 어떻게 그것을 부정하는지 알지 못합니다. 특히 rustfmt에서
위의 형식. 또한 다음과 같이 작성할 수 있습니다.

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 ();

당신이 그것을 좋아한다면.

인지 부하없이 단 몇 초 만에 200 줄 기능을 수행합니다.

특정 기능에 대해 너무 많이 알지 못하는 것 같습니다.
200 LOC는 아마도 단일 책임 원칙을 위반하고
너무 많은. 해결책은 더 적은 작업을 수행하고 분할하는 것입니다. 사실, 나는
그것이 유지 보수성과 가독성을 위해 가장 중요한 것이라고 생각하십시오.

나는 기다림이 제어 흐름 작업의 기본이라고 생각합니다.

그래서?. 사실, 기다리고? 둘 다 효과적인 제어 흐름 작업입니다.
"추출 가치를 문맥에서"라고 말합니다. 즉, 지역에서
컨텍스트에서 await 유형을 갖는 이러한 연산자를 상상할 수 있습니다. impl
미래

-> T 및? : impl 시도-> T.

예외가 있지만 예외입니다.
을 위해 노력.

그리고 여기서 예외는? ?

@andreytkachenko https://github.com/andreytkachenko

@ejmahler https://github.com/ejmahler에 동의합니다. 우린 그러지 말았어야 했어
개발의 다른 측면을 잊어 버리십시오-코드 검토. 소스 코드가있는 파일은
훨씬 더 자주 읽히고 썼습니다.
읽고 이해 한 다음 쓰기.

불일치는 가독성과
인간 공학.

이해하기가 더 쉽습니다.

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

이것은 형식화 방법이 아닙니다. 관용적 rustfmt 형식화
is :

let body : MyResponse = 클라이언트
.get ( "https : // my_api")
.보내다()
.시합?
.into_json ()
.시합?;

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/57640#issuecomment-455810497 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABGmeocFJpPKaypvQHo9LpAniGOUFrmzks5vE3kXgaJpZM4aBlba
.

@ejmahler 우리는 다시 동의하지 않습니다. "숨김"; 동일한 주장 이 wrt 로 ? 연산자 :

? 연산자는 매우 짧으며 과거에 수익을 "숨기기"라는 비판을 받았습니다. 대부분의 경우 코드는 작성되지 않고 읽습니다. ?! 이름을 바꾸면 두 배 더 길어 지므로 간과하기가 더 어려워집니다.

그럼에도 불구하고 우리는 궁극적으로 ? 안정화 시켰고 그 이후로 예언이 실현되지 못한 것 같습니다.
나에게 await 접미사는 자연스러운 읽기 순서를 따릅니다 (적어도 왼쪽에서 오른쪽으로 쓰는 언어 사용자의 경우). 특히 데이터 흐름 순서를 따릅니다.

구문 강조는 말할 것도 없습니다. await 관련 항목은 밝은 색상으로 강조 표시 할 수 있으므로 한 눈에 볼 수 있습니다. 따라서 실제 await 단어 대신 기호가 있더라도 구문 강조 코드에서 여전히 읽기 쉽고 찾을 수 있습니다. 그래도 여전히 await 단어를 사용하는 것을 선호합니다. 기호 대신 await 단어 만 사용하면 기다리고있는 모든 항목에 대해 코드를 grep하는 것이 더 쉽습니다. @ 또는 #과 같이 문법에 따라 의미가 다릅니다.

이건 로켓 과학이 아니야

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

postfix ... 는 매우 읽기 쉽고, 한 눈에 놓치기 어렵고, 매우 직관적입니다. 미래의 결과가 나올 때까지 기다리는 동안 코드가 뒤 따르는 것처럼 자연스럽게 읽히기 때문입니다. 모든 사람들이 이전에 타원을 본 적이 있기 때문에 우선 순위 / 매크로 헛소리가 필요하지 않으며 익숙하지 않은 신호로 인한 추가 라인 노이즈도 없습니다.

(@solson에게 사과드립니다)

@ ben0x539 future()....start 같은 결과 멤버에 액세스 할 수 있다는 의미입니까? 또는 range()..... 와 같은 범위 결과를 기다리십니까? 그리고 현재 줄임표 .. 는 오른쪽에 이항 연산자 또는 괄호가 있어야하기 때문에 no precedence/macro shenanigans necessary and 정확히 의미하는 방법은 무엇입니까?

예,? 연산자가 있습니다. 나는 이미
예외. 하지만 예외입니다. 대부분의 제어 흐름은
Rust 프로그램은 접두사 키워드를 통해 발생합니다.

2019 년 1 월 19 일 토요일 오후 1:51 Benjamin Herr [email protected]
썼다 :

이건 로켓 과학이 아니야

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

postfix ... 매우 읽기 쉽고 한 눈에 놓치기 어렵고 슈퍼
자연스럽게 코드가 후미로 읽히기 때문에 직관적입니다.
미래의 결과가 나오기를 기다리는 동안. 아니
우선 순위 / 매크로 헛소리가 필요하며 추가 라인 노이즈가 없습니다.
모든 사람들이 전에 타원을 본 적이 있기 때문에 익숙하지 않은 인장.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/57640#issuecomment-455818177 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABGmen354fhk7snYsANTfp5oOuDb4OLYks5vE5NSgaJpZM4aBlba
.

@HeroicKatora 약간 인위적인 것처럼 보이지만 그래요. 다른 접미사 솔루션이 제안한 것처럼 접미사 연산이기 때문에 await x? 대해 반 직관적 인 우선 순위가 필요하지 않으며 매크로가 아닙니다.

헉헉

예,? 연산자가 있습니다. 나는 이미 예외가 있음을 인정했습니다. 하지만 예외입니다.

keyword expr 맞는 두 가지 표현식 형식, 즉 return expr 및 break expr 있습니다. 전자가 후자보다 더 일반적입니다. continue 'label 형식은 식이지만 keyword expr 형식이 아니기 때문에 실제로 계산되지 않습니다. 이제 2 개의 전체 접두사 키워드 단항 표현식 양식과 1 개의 후위 단항 표현식 양식이 있습니다. ? 및 await 가 await 및 return 보다 더 유사하다는 사실을 고려하기 전에는 거의 return/break expr 호출하지 않습니다. ? 에 대한 예외가되는 규칙.

Rust 프로그램의 대부분의 제어 흐름은 접두사 키워드를 통해 발생합니다.

앞서 언급했듯이 break expr 는 그다지 일반적이지 않습니다 ( break; 가 더 일반적이고 return; 이 더 일반적이며 단항 표현식 형식이 아닙니다). 남아있는 것은 초기 return expr; 이며 이것이 match , ? 보다 훨씬 더 일반적이라는 것이 분명하지 않습니다. if let s 및 else s 및 for 루프. try { .. } 안정화되면 ? 가 더 많이 사용될 것으로 예상합니다.

@ ben0x539 variadic generics를 사용할 준비가되면 ... 를 예약해야한다고 생각합니다.

여기서 접미사 구문으로 혁신하는 아이디어가 정말 마음에 듭니다. 그것은 흐름에서 훨씬 더 의미가 있으며 접두사 try! 에서 접미사 ? 갔을 때 얼마나 더 나은 코드가 바뀌 었는지 기억합니다. Rust 커뮤니티에서 코드를 얼마나 개선했는지에 대한 경험을 한 많은 사람들이 있다고 생각합니다.

.await 아이디어가 마음에 들지 않으면 실제 접미사 연산자를 찾기 위해 창의력을 발휘할 수있을 것입니다. 한 가지 예는 대기에 ++ 또는 @ 를 사용하는 것입니다.

:( 더 이상 기다리고 싶지 않습니다.

모두가 매크로 구문에 익숙합니다. 다른 의견으로 시작하는이 스레드의 대부분의 사람들은 결국 매크로 구문을 선호하는 것 같습니다.

물론 "마법의 매크로"가 될 수 있지만 사용자는 매크로 확장이 어떻게 생겼는지에 대해 거의 신경 쓰지 않으며 그렇게하는 사람들에게는 문서에서 뉘앙스를 설명하는 것이 쉽습니다.

일반 매크로 구문은 애플 파이와 비슷합니다. 모두가 두 번째로 좋아하는 옵션이지만 결과적으로 가족이 가장 좋아하는 옵션 [0]입니다. 중요한 것은 try! 나중에 언제든지 변경할 수 있습니다. 그러나 가장 중요한 것은 우리 모두가 더 빨리 동의할수록 우리 모두가 실제로 사용하고 생산성을 높일 수 있다는 것입니다!

[0] (첫 분 참조) https://www.ted.com/talks/kenneth_cukier_big_data_is_better_data/transcript?language=en

match, if, if let, while, while let 및 for는 모두 퍼베이시브 제어 흐름입니다.
접두사를 사용하는. 쉬는 척하고 계속하는 것이 유일한 제어 흐름
키워드는 실망스럽게도 오해의 소지가 있습니다.

2019 년 1 월 19 일 토요일 오후 3:37 Yazad Daruvala [email protected]
썼다 :

:( 더 이상 기다리고 싶지 않습니다.

누구나 매크로 구문에 익숙합니다.이 스레드의 대부분의 사람들은
다른 의견으로 시작하면 결국 매크로 구문을 선호하는 것 같습니다.

물론 "마법의 매크로"가 되겠지만 사용자는 매크로가 무엇인지 거의 신경 쓰지 않습니다.
확장은 보이며 그렇게하는 사람들에게는 쉽게 설명 할 수 있습니다.
문서의 뉘앙스.

일반 매크로 구문은 애플 파이와 비슷합니다.
가장 좋아하는 옵션이지만 결과적으로 가족이 가장 좋아하는 옵션 [0].
중요한 것은 try! 나중에 언제든지 변경할 수 있습니다. 하지만 대부분
중요한 것은 우리 모두가 더 빨리 동의할수록 우리 모두가 더 빨리 시작할 수 있다는 것입니다.
실제로 사용하고 생산성을 높이십시오!

[0] (처음 1 분에 참조)
https://www.ted.com/talks/kenneth_cukier_big_data_is_better_data/transcript?language=en

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/57640#issuecomment-455824275 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABGmesz5_LfDKdcKn6zMO5uuSJs9lFiYks5vE6wygaJpZM4aBlba
.

@mitsuhiko 동의합니다! Postfix는 체인으로 인해 더 소박한 느낌이 듭니다. 내가 제안한 fut@await 구문은 다른 제안만큼 단점이 많지 않은 또 다른 흥미로운 옵션이라고 생각합니다. 너무 멀리 떨어져 있고 좀 더 현실적인 버전이 더 나은지 확실하지 않습니다.

헉헉

match, if, let, while, while let 및 for는 모두 접두사를 사용하는 퍼베이시브 제어 흐름입니다. 중단 및 계속하는 척하는 것이 유일한 제어 흐름 키워드입니다.

오해의 소지가 전혀 없습니다. 이러한 구성에 대한 관련 문법은 대략 다음과 같습니다.

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 ","?;

여기에서 양식은 if/while expr block , for pat in expr block 및 match expr { pat0 => expr0, .., patn => exprn } 입니다. 이러한 모든 형식에서 뒤에 오는 키워드 앞에는 키워드가 있습니다. 이것이 "접두사 사용"이라는 뜻인 것 같습니다. 그러나 이들은 모두 블록 형식 이며 단항 접두사 연산자가 아닙니다 . 따라서 await expr 와의 비교는 일관성이나 규칙이 없기 때문에 잘못된 것입니다. 블록 양식과 일관성을 유지하려는 경우 await block 가 아니라 await expr .

@mitsuhiko 동의합니다! Postfix는 체인으로 인해 더 소박한 느낌이 듭니다.

Rust는 이원 적입니다. 명령형 및 기능적 접근 방식을 모두 지원합니다. 다른 경우에 각각 더 적합 할 수 있기 때문에 괜찮다고 생각합니다.

모르겠어요. 두 가지를 모두 갖추면 좋을 것 같습니다.

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

한동안 Scala를 사용하면서 저도 그렇게 작동하는 많은 것들을 아주 좋아했습니다. 특히 match 및 if 는 Rust의 접미사 위치에 있으면 좋을 것입니다.

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

지금까지 요약

옵션 매트릭스 :

• 보트없이
• 메흐 코드
• HeroicKatora
• AaronFriel
• EyeOfPython

옵션 요약 매트릭스 ( @ 를시길로 사용하지만 대부분의 경우 가능) :

| 이름 | Future<T> | Future<Result<T, E>> | Result<Future<T>, E> |
| --- | --- | --- | --- |
| PREFIX | -| -| -|
| 키워드 매크로 | await!(fut) | await!(fut)? | await!(fut?) |
| 키워드 기능 | await(fut) | await(fut)? | await(fut?) |
| 유용한 우선 순위 | await fut | await fut? | await (fut?) |
| 명백한 우선 순위 | await fut | await? fut | await fut? |
| POSTFIX | -| -| -|
| 키워드로 Fn | fut(await) | fut(await)? | fut?(await) |
| 키워드 필드 | fut.await | fut.await? | fut?.await |
| 키워드 방법 | fut.await() | fut.await()? | fut?.await() |
| 접미사 키워드 매크로 | fut.await!() | fut.await!()? | fut?.await!() |
| 우주 키워드 | fut await | fut await? | fut? await |
| Sigil 키워드 | fut@await | fut@await? | fut?@await |
| Sigil | fut@ | fut@? | fut?@ |

"Sigil Keyword"의 sigil _cannot_은 # . 그러면 r 라는 미래로 할 수 없었습니다. ... 시길 이 내 첫 번째 걱정처럼 토큰 화를 변경할 필요가 없기 때문 입니다.

더 많은 실제 사용 (urlo에 여러 개의 await 다른 _real_ 사용 사례 를 PM 및 추가하겠습니다) :

| 이름 | (필수) Client |> Client::get |> RequestBuilder::send |> await |> ? |> Response::json | > ? |
| --- | --- |
| PREFIX | -|
| 키워드 매크로 | await!(client.get("url").send())?.json()? |
| 키워드 기능 | await(client.get("url").send())?.json()? |
| 유용한 우선 순위 | (await client.get("url").send()?).json()? |
| 명백한 우선 순위 | (await? client.get("url").send()).json()? |
| POSTFIX | -|
| 키워드로 Fn | client.get("url").send()(await)?.json()? |
| 키워드 필드 | client.get("url").send().await?.json()? |
| 키워드 방법 | client.get("url").send().await()?.json()? |
| 접미사 키워드 매크로 | client.get("url").send().await!()?.json()? |
| 우주 키워드 | client.get("url").send() await?.json()? |
| Sigil 키워드 | client.get("url").send()@await?.json()? |
| Sigil | client.get("url").send()@?.json()? |

편집 참고 : Response::json 도 Future 반환하는 것이 합리적 일 수 있다고 지적되었습니다. 여기서 send 는 나가는 IO 및 json 기다립니다.

접두사 옵션에 대한 대략적인 합의가있는 것 같습니다. 명백한 우선 순위 ( await? 설탕과 함께)가 가장 바람직합니다. 그러나 많은 사람들이 위와 같이 더 쉽게 연결하기 위해 접미사 솔루션을 찬성했습니다. 접두사 선택에는 대략적인 합의가 있지만 어떤 후위 솔루션이 가장 좋은지에 대한 합의는없는 것 같습니다. 제안 된 모든 옵션은 혼동을 유발합니다 (키워드 강조 표시로 완화).

• Fn With Keyword => await 라는 인수로 fn 호출
• 키워드 필드 => 필드 액세스
• 키워드 메소드 => 메소드 호출
• 매크로 (접두사 또는 접미사) => await 키워드입니까?
• 공백 키워드 => 그룹을 한 줄로 나눕니다 (여러 줄보다 더 좋습니까?).
• Sigil => 이미 sigil-heavy로 인식되는 언어에 새로운 sigils 추가

다른보다 과감한 제안 :

• 접두사 (명백한 우선 순위)와 접미사 "필드"를 모두 허용합니다 (이를 일반화 된 패턴으로 만들기 위해 앞으로 match , if 등과 같은 더 많은 키워드에 적용될 수 있지만 불필요합니다.) 이 토론에 대한 부록) [[참조] (https://github.com/rust-lang/rust/issues/57640#issuecomment-455827164)]
• 선물을 해결하기위한 패턴에서 await (연쇄 없음) [[참조] (https://github.com/rust-lang/rust/issues/57640)]
• 접두사 연산자를 사용하되 지연 허용 [[참조] (https://github.com/rust-lang/rust/issues/57640#issuecomment-455782394)]

키워드 매크로 await!(fut) 사용한 안정화는 물론 기본적으로 위의 모든 항목과 향후 호환되지만 매크로가 일반 식별자 대신 키워드를 사용하도록해야합니다.

누군가가 하나의 체인에서 두 개의 await 를 사용하는 거의 실제와 같은 예제를 가지고 있다면, 저는 그것을보고 싶습니다. 지금까지 아무도 공유하지 않았습니다. 그러나 reqwest 예제에 표시된 것처럼 접미사 await 는 체인에서 두 번 이상 await 가 필요하지 않은 경우에도 유용합니다.

이 요약 댓글 위에 주목할만한 내용을 놓친 경우 urlo에서 나를 PM하고 추가해 보겠습니다. (큰 목소리 편애를 피하기 위해 다른 사람의 댓글을 추가해야하지만)

개인적으로 저는 역사적으로 명백한 우선 순위를 가진 접두사 키워드를 선호했습니다. 나는 여전히 키워드 매크로 await!(fut) 안정화하는 것이 실제 사용 사례에서 대기가 발생하는 위치에 대한 실제 정보를 수집하는 데 유용 할 것이라고 생각하며 나중에 비 매크로 접두사 또는 접미사 옵션을 추가 할 수 있습니다. .

하지만 위의 요약을 작성하는 과정에서 저는 "키워드 필드"를 좋아하기 시작했습니다. "Space Keyword"는 여러 줄로 나눌 때 기분이 좋습니다.

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

그러나 한 줄에 client.get("url").send() await?.json()? 라는 식을 잘못 그룹화하는 어색한 중단이 발생합니다. 그러나 키워드 필드를 사용하면 client.get("url").send().await?.json()? 두 가지 형식 모두에서보기 좋습니다.

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

액션이기 때문에 "키워드 방법"이 더 잘 흐를 것이라고 생각합니다. 원하는 경우 Future 에서 "실제"방법으로 만들 수도 있습니다 _.

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

( extern "rust-await" 는 물론 실제로 await를 수행하는 데 필요한 모든 마법을 암시하고 실제로 실제 fn이 아닐 것입니다. 키워드가 있으면 구문이 메소드처럼 보이기 때문에 주로 존재합니다. 방법이 사용됩니다.)

접두사 (명백한 우선 순위) 및 접미사 "필드"모두 허용 ...

접미사 구문이 선택되면 (함께 또는 접두사 1 대신에) 확실히 향후 논의를위한 논쟁이 될 것입니다. 이제 우리는 접두사와 접미사 표기법 모두에서 작동하는 키워드가 있습니다. 다른 하나는 의미가있는 경우 둘 다 허용하고 구문의 유연성을 높이면서 규칙을 통합 할 수 있습니다. 나쁜 생각 일 수도 있고 거부 될 수도 있지만, await postix 표기법을 사용한다면 앞으로 논의해야 할 논의 일 것입니다.

이 구문에는 문자열 await를 포함하지 않는 구문이 허용 될 가능성이 거의 없다고 생각합니다.

: +1 :

여기에서 많은 예제를 본 후 무작위로 생각했습니다 ( 예 : @mehcode 's ) : .await 에 대해 기억 나는 불만 중 하나는보기가 너무 어렵다는 것입니다 †,하지만 기다릴 수있는 것은 일반적으로 오류가 있지만 .await? 라는 사실은 어쨌든 그것에 대한 추가 관심을 끄는 데 도움이됩니다.

† 키워드를 강조하지 않는 것을 사용하는 경우

헉헉

영어처럼 읽히지 않는 구문에 반대합니다.

request.get().await 와 같은 것은 body.lines().collect() 와 같이 읽습니다. "연쇄 된 반복기 메서드의 무리"에서 _prefix_는 실제로 더 나쁘다고 생각합니다. 처음에 "대기"라고 말한 것을 기억해야하기 때문이며, 당신이 무슨 소리를 듣게 될지 언제들을 지 알 수 없기 때문입니다. 기다려, 마치 정원 길 문장 처럼.

그리고 몇 년 동안 프로덕션 코드에서 사용한 후, 수율 포인트가 어디에 있는지 아는 것이 절대적으로 중요하다고 생각합니다. 함수 인 경우 들여 쓰기 줄을 훑어 볼 때인지 부하없이 몇 초 만에 200 줄 함수의 모든 co_await / yield 수익을 선택할 수 있습니다.

이것은 Rust의 표현 지향적 특성을 감안할 때 절대적으로 지원하지 않을 제한 인 표현식 내부에 어떤 것도 없다는 것을 의미합니다. 그리고 적어도 C #의 await 를 사용하면 CallSomething(argument, await whatever.Foo() 를 갖는 것이 절대적으로 그럴듯합니다.

async _will_이 식 중간에 나타나는 것을 감안할 때 접두사보다 접두사에서 보는 것이 더 쉬운 이유를 이해할 수 없습니다.

'if, while, match, return'과 같은 수준의 존중을 받아야합니다. 그것들 중 어느 것이 접미사 연산자라면-Rust 코드를 읽는 것은 악몽이 될 것입니다.

return (및 continue 및 break ) 및 while 는 항상 ! 및 () 반환하므로 체인에 _completely_ 쓸모없는 것으로 유명합니다 for 를 생략했지만, 특히 rayon에서 나쁜 영향없이 .for_each() 를 사용하여 잘 작성된 코드를 보았습니다.

우리는 아마도 async/await 이 주요 언어 기능이 될 것이라는 사실에 화해해야 할 것입니다. 모든 종류의 코드에 나타납니다. 생태계에 퍼질 것입니다. 어떤 곳에서는 ? 만큼 흔합니다. 사람들은 그것을 배워야 할 것입니다.

결과적으로 우리는 구문 선택이 처음에 어떻게 느껴질 지보다 오랫동안 사용 후 어떻게 느껴질 지 의식적으로 집중하고 싶을 수 있습니다.

또한 제어 흐름 구조가 진행되는 한 await 는 다른 종류의 동물이라는 것을 이해해야합니다. return , break , continue 및 yield 와 같은 구문은 jmp 측면에서 직관적으로 이해할 수 있습니다. 이것을 보면 우리가 신경 쓰는 제어 흐름이 다른 곳으로 이동하기 때문에 눈이 화면을 가로 질러 튀어 오릅니다. 그러나 await 는 기계의 제어 흐름에 영향을 주지만 우리 눈과 코드에 대한 직관적 인 이해에 중요한 제어 흐름을 이동하지는 않습니다.

우리는 return 또는 break 무조건 호출을 연결하려는 유혹을받지 않습니다. 비슷한 이유로, 우리는이를 수용하기 위해 우선 순위 규칙을 변경하고 싶지 않습니다. 이러한 연산자는 우선 순위가 낮습니다. 그들은 모든 것을 오른쪽으로 가져 가서 어딘가로 돌려 보내고 그 함수 나 블록 내에서 실행을 끝냅니다. 그러나 await 연산자는 연결되기를 원합니다. 그것은 표현의 끝이 아니라 필수적인 부분입니다.

이 스레드의 토론과 예제를 고려한 결과, 놀라운 우선 순위 규칙을 후회하기 위해 살게 될 것이라는 갉아 먹는 감각이 남아 있습니다.

스토킹 말 후보자는 당분간 await!(expr) 를 가지고 가고있는 것 같고, 나중에 더 나은 것이 해결되기를 바라고 있습니다. @Centril 의 발언을 읽기 전에 나는 거의 모든 구문으로이 중요한 기능을 꺼내기 위해 이것을 지원했을 것입니다. 그러나 그의 주장은 이것이 단지 대처할 것이라고 확신합니다. 우리는 Rust에서 메소드 호출 체인이 중요하다는 것을 알고 있습니다. 이로 인해 ? 키워드가 채택되었으며, 이는 널리 사용되고 있으며 매우 성공적이었습니다. 우리가 아는 구문을 사용하면 실망 스럽습니다. 실제로 기술 부채를 추가하는 것입니다.

이 스레드의 초기에 @withoutboats 는 기존 옵션 4 개만 실행 가능 expr await 구문 만이 우리를 장기적으로 행복하게 만들 것입니다. 이 구문은 이상한 우선 순위 놀라움을 생성하지 않습니다. ? 연산자의 접두사 버전을 만들도록 강요하지 않습니다. 메서드 체이닝과 잘 작동하며 왼쪽에서 오른쪽으로의 제어 흐름을 분리하지 않습니다. 성공적인 ? 연산자는 접미사 연산자의 선례 역할을하며 await 는 return , break 보다 실제로 ? 와 비슷합니다. break 또는 yield . 후위 비 기호 연산자가 Rust에서 새로울 수 있지만, async/await 은 빠르게 익숙해 질 수있을만큼 널리 퍼질 것입니다.

접미사 구문에 대한 모든 옵션이 실행 가능한 것처럼 보이지만 expr await 에는 몇 가지 장점이 있습니다. 이 구문은 await 가 키워드임을 명확히하여 마법 제어 흐름을 강조하는 데 도움이됩니다. expr.await , expr.await() expr.await! , expr.await!() 등과 비교하면 이것이 필드 / 메서드 / 매크로처럼 보인다고 설명 할 필요가 없지만 실제로는 이 특별한 경우

await 를 @ await 로 철자하거나 구문 분석 문제를 일으키지 않는 다른 기호를 사용하는 것이 매력적입니다. 확실히 그것을 보증하기에 충분히 중요한 운영자입니다. 그러나 결국 await 철자가되어야한다면 괜찮습니다. 접미사 위치에있는 한.

누군가가 _real_ 예제를 언급했듯이 ... 나는 매우 비동기적이고 선물 0.1 await (내가 알고있는 매우 실험적인)를 사용하는 23,858 라인의 rust 코드베이스를 유지하고 있습니다 (tokei에 따르면). spelunking (편집 됨)을 시작합시다 (모든 것이 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)
}

이제 이것을 가장 인기있는 접두사 변형으로 변환 해 보겠습니다. 명백한 이유로 이것은 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)
}

마지막으로 이것을 제가 가장 좋아하는 접미사 변형 인 "접미사 필드"로 변환 해 보겠습니다.

// 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)
}

이 연습 후에 나는 많은 것을 발견한다.

• 나는 지금 await? foo 강하게 반대합니다. 단순한 표현에는 좋지만 ? 는 복잡한 표현에서는 잃어버린 느낌이 듭니다. 접두사를해야한다면 "유용한"우선 순위를 갖고 싶습니다.

• 접미사 표기법을 사용하면 문을 결합하고 불필요한 let 바인딩을 줄일 수 있습니다.

• 접미사 _field_ 표기법을 사용하면 rustfmt 어법에서 자체 줄이 아닌 .await? 가 기다리는 줄에 표시되는 것을 강력하게 선호합니다.

위의 생략 부호 "..."는 간결함과 다른 것을 기대하는 일시 중지를 상징적으로 나타내는 영어로 모두 감사합니다. (비동기 동작이 작동하는 방식처럼!) 또한 서로 잘 연결됩니다.

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

다른 옵션이 간결하고 시각적으로 의미가 있을지 의심됩니다.

ㅏ

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

비

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

긴 기다림 체인을 갖는 것이 좋은 형태로 간주되어야합니까?

단순히 일반 Future 결합자를 사용하지 않는 이유는 무엇입니까?

실제로 실패시 백업 동작을 원하는 경우 일부 표현식은 대기 체인으로 잘 변환되지 않습니다.

개인적으로 나는 이것을 생각한다 :

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

value.unwrap()

이보다 훨씬 더 자연스럽게 읽습니다.

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()

결국 우리는 여전히 제로 비용 선물의 모든 힘을 가지고 있습니다.

그것을 고려하십시오.

@EyeOfPython @ 에서 future@await @ 이외의 다른 선택이 있음을 강조하고 싶습니다. future~await 작성할 수 있습니다. 여기서 ~ 는 세미 하이픈처럼 작동하며 가능한 모든 접미사 연산자에 대해 작동합니다.

하이픈 - 은 (는) 마이너스 연산자와 음수 연산자로 이미 사용되었습니다. 더 이상 좋지 않습니다. 그러나 ~ 는 Rust에서 힙 객체를 나타내는 데 사용되었으며, 그렇지 않으면 어떤 프로그래밍 언어에서도 거의 사용되지 않았습니다. sould는 다른 언어의 사람들에게 혼란을 덜줍니다.

@earthengine 좋은 생각이지만 future~ 를 사용하면 ~ 가 await 키워드처럼 작동하는 미래를 기다린다는 의미입니다. ( ? 기호처럼)

미래 | 결과의 미래 | 미래의 결과
-| -| -
미래 ~ | 미래 ~? | 미래? ~

또한 다음과 같은 연결 선물 :

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

Go가 비동기 프로그래밍을 구현하는 방법을 살펴보고 흥미로운 점을 발견했습니다. Go의 선물에 가장 가까운 대안은 채널입니다. 그리고 값을 기다리는 await 또는 다른 비명 구문 대신 Go 채널은 해당 용도로 <- 연산자를 제공합니다. 저에게는 꽤 깨끗하고 간단 해 보입니다. 이전에는 사람들이 Go의 간단한 구문과 우수한 비동기 기능을 칭찬하는 방식을 자주 보았으므로 경험을 통해 무언가를 배우는 것이 좋습니다.

불행하게도, Go에서보다 Rust 소스 코드에 꺾쇠 괄호가 훨씬 많기 때문에 정확히 동일한 구문을 가질 수 없었습니다. 대부분 제네릭 때문입니다. 이로 인해 <- 연산자가 정말 미묘하고 작업하기에 즐겁지 않습니다. 또 다른 단점은 함수 시그니처에서 -> 와 반대되는 것으로 볼 수 있으며 그렇게 생각할 이유가 없다는 것입니다. 그리고 또 다른 단점은 <- 시길이 placement new 로 구현되어 사람들이 잘못 해석 할 수 있다는 것입니다.

따라서 구문을 사용한 몇 가지 실험 후 <-- 시길에서 중지했습니다.

let output = <-- future;

async 컨텍스트에서 <-- 는 <- 미만이지만 매우 간단합니다. 그러나 대신 <- 및 접두사 await 보다 큰 이점을 제공합니다. 들여 쓰기와 잘 어울립니다.

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);
}

나에게이 연산자는 await (코드 컨텍스트에서 다른 키워드 나 변수와 더 비슷해 보임)보다 훨씬 더 독특하고 찾기 쉽습니다. 불행히도 Github에서는 내 코드 편집기보다 더 얇아 보이지만 치명적이지 않으며 우리는 그것으로 살 수 있다고 생각합니다. 누군가가 불편하다고 느끼더라도 다른 구문 강조 표시 또는 더 나은 글꼴 (특히 합자 사용)이 모든 문제를 해결합니다.

이 구문을 좋아하는 또 다른 이유는 개념적으로 "아직 여기에없는 것"으로 표현할 수 있기 때문입니다. 화살표의 오른쪽에서 왼쪽 방향은 텍스트를 읽는 방향과 반대이므로 "미래에서 오는 것"으로 설명 할 수 있습니다. <-- 연산자의 긴 모양은 "일부 내구성있는 작업이 시작됨"을 암시합니다. future 에서 오는 꺾쇠 괄호와 두 개의 하이픈은 "연속 폴링"을 상징 할 수 있습니다. 그리고 우리는 이전처럼 "대기"로 읽을 수 있습니다.
어떤 종류의 깨달음은 아니지만 재미있을 수 있습니다.

이 제안에서 가장 중요한 것은 인체 공학적 방법 체인도 가능하다는 것입니다. 이전에 제안한 지연 접두사 연산자 의 아이디어가 여기에 적합합니다. 이런 식으로 우리는 접두사 및 접미사 await 구문의 세계에서 최상의 결과를 얻을 수 있습니다. 저는 개인적으로 제가 이전에 여러 차례 원했던 유용한 추가 기능 ( 지연된 역 참조 및 지연된 부정 구문) 도 소개되기를 바랍니다.

여기에서 지연된 단어가 적절한 지 잘 모르겠습니다. 다른 이름을 지정해야 할 수도 있습니다.

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

let not_empty = some_vec.!is_empty();

let deref = value.*as_ref();

연산자 우선 순위는 왼쪽에서 오른쪽으로 매우 분명해 보입니다.

이 구문이 bool 속성을 부정하고 반환하는 용도로만 사용되는 is_not_* 함수를 작성할 필요가 줄어들기를 바랍니다. 그리고 어떤 경우에는 부울 / 해석 표현식을 사용할 때 더 깔끔해질 것입니다.

마지막으로 @mehcode에서 게시 한 실제 예제에 적용했으며 <-- 가 메서드 호출 체인 내에서 async 함수를 적절하게 강조하는 방식이 마음에 듭니다 . 반대로 await 접미사는 일반 필드 액세스 또는 함수 호출 (구문에 따라 다름)처럼 보이며 특별한 구문 강조 또는 형식화 없이는 구분하기가 거의 불가능합니다.

// 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)
}

결국, 이것이 제가 사용하고 싶은 구문입니다.

헉헉

긴 기다림 체인을 갖는 것이 좋은 형태로 간주되어야합니까? 단순히 일반 Future 결합자를 사용하지 않는 이유는 무엇입니까?

오해하지 않았는지 잘 모르겠지만 배타적이지는 않지만 여전히 조합자를 사용할 수 있습니다.

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

그러나이 작업을 수행하려면 and_then 절에 입력 할 필요가 FnOnce(T) -> impl Future<_> ,뿐만 아니라에서 FnOnce(T) -> U . 미래에 체인 콤비를 수행하고 그 결과는 후위에 paranthesis없이 정상적으로 작동합니다 :

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

이 게시물에서는 수정 후의 경우 연산자 우선 순위 문제에 초점을 맞출 것입니다. 내가 말할 수있는 한, 우리는 적어도 어느 정도 작동하는 세 가지 실행 가능한 대안을 가지고 있으며, 각각은 현재 구문에서 이러한 우선 순위를 갖는 하나의 사후 수정 표현식으로 예시됩니다. 나는 어떤 제안도 현재 운영자의 우선 순위를 변경해서는 안된다고 강하게 느낍니다.

• 메서드 호출 ( future.await() )
• 필드 표현식 ( future.await )
• 함수 호출 ( future(await) )

기능상의 차이는 작지만 존재합니다. 나는이 모든 것을 받아 들일 것이며, 이것은 대부분 미세 조정입니다. 그것들을 모두 보여주기 위해서는 몇 가지 유형이 필요합니다. 예제의 인위성에 대해 언급하지 마십시오. 이것은 모든 차이점을 한 번에 보여주는 가장 압축 된 버전입니다.

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)

• 메서드 호출 : foo.member.await()(42)
  가장 강하게 결합하므로 괄약근이 전혀 없습니다.
• 회원 : (foo.member.await)(42)
  이것이 콜 러블 일 때 기다린 결과 주위에 패란 테 시스가 필요합니다. 이것은 콜 러블을 멤버로 갖는 것과 일치합니다. 그렇지 않으면 멤버 함수 호출과 혼동됩니다. 이것은 또한 패턴으로 구조를 해체 할 수 있음을 시사합니다 : let … { await: value } = foo.member; value(42) 어떻게 든?
• 함수 호출 : (foo.member)(await)(42)
  함수 호출로 작동하므로 구조화 (멤버 이동)를 위해 패란 테 시스가 필요합니다.

멤버 이동을 통해 입력 구조체를 구조화하지 않거나 결과를 콜러 블로 호출하지 않을 때 모두 동일하게 보입니다.이 세 가지 우선 순위 클래스가 서로 바로 뒤 따르기 때문입니다. 미래가 어떻게 행동하기를 원합니까?

메서드 호출과 가장 유사한 방법은 self 하는 또 다른 메서드 호출입니다.

멤버에 대한 가장 좋은 병렬은 암시 적 멤버 await 만 가지고 있으므로 여기에서 이동하여 구조화되고이 이동은 암시 적으로 미래를 기다리는 구조체입니다. 이것은 가장 덜 산란 한 것처럼 느껴집니다.

함수와 유사하게 호출은 클로저의 동작입니다. 이 솔루션을 언어 코퍼스에 가장 깔끔하게 추가하는 것을 선호하지만 (구문에서 형식의 가능성과 가장 유사 함) 메서드 호출에 대한 긍정적 인 점이며 .await 는 다른 것보다 길지 않습니다.

@HeroicKatora libsyntax 에서 foo.await(42) 를 허용하기 위해 특별한 경우 .await 를 사용할 수 있지만 이것은 일관성이 없거나 ad-hoc입니다. 그러나 (foo.await)(42) 는 마감을 출력하는 선물이 존재하는 동안 그다지 흔한 것은 아니기 때문에 유용 할 것 같습니다. 따라서 일반적인 경우에 최적화하면 .await 에 () 를 추가하지 않아도 균형을 이룰 수 있습니다.

@Centril 동의합니다. 일관성이 중요합니다. 비슷한 행동을 몇 가지 보면 합성을 통해 다른 사람을 추론하고 싶습니다. 그러나 여기서 .await 어색해 보입니다. 특히 위의 예가 암시 적 분해와 유사하다는 것을 분명히 보여주는 경우입니다 (이러한 효과가 발생하는 다른 구문을 찾을 수 없다면?). Destructuring을 보면 즉시 let-bindings 등과 함께 사용할 수 있는지 궁금합니다. 그러나 이러한 멤버가없는 원래 유형을 해체하거나 특히 유형이 impl Future<Output=F> 경우에는 이것이 불가능합니다. await _ = 대신에 let _ = , funnily¹).

그렇다고 우리가 문법을 사용하는 것을 금지하지는 않습니다. 나는 그것을 배우는 데 대처할 수 있다고 생각하고 그것이 최종적인 것으로 밝혀지면 그것을 활기차게 사용할 것입니다. 그러나 그것은 명백한 약점처럼 보입니다.

¹ 패턴에서 이름 뒤에 ? 을 허용하여 ? 를 허용하면서 일관성을 유지할 수 있습니다.

• await value? = failing_future();

Result 의 Ok 부분과 일치합니다. 이것은 다른 맥락에서도 탐구하는 것이 흥미롭지 만 오히려 주제에서 벗어난 것 같습니다. 또한 동시에 await 에 대한 접두사 및 접미사 구문을 일치시킵니다.

그렇다고 우리가 문법을 사용하는 것을 금지하지는 않습니다. 나는 그것을 배우는 데 대처할 수 있다고 생각하고 그것이 최종적인 것으로 밝혀지면 그것을 활기차게 사용할 것입니다. 그러나 그것은 명백한 약점처럼 보입니다.

나는 모든 솔루션이 어떤 차원이나 사례에서 몇 가지 단점을 가질 것이라고 생각합니다. 일관성, 인체 공학, 체인 가능성, 가독성, ... 이는 정도, 사례의 중요성, 일반적인 Rust 코드 및 API에 대한 적합성 등의 문제가됩니다.

사용자가 foo.await(42) 쓰는 경우 ...

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

    foo.closure(42);
}

... 우리는 이미 좋은 진단을 제공합니다.

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

이것을 foo.await(42) 에 맞게 조정하는 것은 상당히 달성 가능해 보입니다. 사실, 제가 볼 수있는 한, foo.await(42) 가 쓰여질 때 사용자가 (foo.await)(42) 의도하고 있으므로 MachineApplicable 에서 cargo fix ed가 될 수 있습니다. 방법. 실제로 foo.await 안정화하지만 foo.await(42) 허용하지 않는 경우 foo.await(42) 가 처음에는 합법적이지 않기 때문에 필요할 경우 나중에 우선 순위를 변경할 수도 있다고 생각합니다.

더 많은 중첩이 작동 할 것입니다 (예 : 폐쇄 결과의 미래-일반적이지 않음).
```녹
struct HasClosure fn _foo ()-> 결과 <(), ()> {
let foo : HasClosure <_ i = "27"> = HasClosure {클로저 : Ok (| x | {})};

foo.closure?(42);

Ok(())

}

예 : 폐쇄 결과의 미래-일반적이지 않음

추가 접미사 ? 연산자는 모든 접미사 예에서 구문을 수정하지 않고이를 명확하게 만듭니다. 조정할 필요가 없습니다 . 문제는 명시 적으로 필드 인 .member 와 먼저 적용하기 위해 이동-구조 분해가 필요하다는 것입니다. 그리고 저는 이것이 쓰기가 어려울 것이라고 말하고 싶지 않습니다. 나는 이것이 예를 들어 일치로 변환 될 수있는 다른 .member 사용과 일치하지 않는 것처럼 보인다고 말하고 싶습니다. 원래 포스트는 그 점에서 긍정과 부정에 무게를 두었습니다.

편집 : future.await(42) 에 맞게 조정하면 의도하지 않은 추가 위험이있을 수 있습니다. b) 우리가 await 논쟁을주고 자하는 미래의 발전을 억제합니다. 그러나 이전에 언급했듯이 Future 조정하여 마감을 반환하는 것이 가장 시급한 문제는 아닙니다.

@novacrazy 단순히 일반 Future 결합

Futures 0.3에 대해 얼마나 많은 경험을 가지고 있는지 잘 모르겠지만 일반적인 기대는 combinator가 많이 사용되지 않고 기본 / 특이 적 사용이 async / await 일 것이라는 것입니다.

Async / await는 컴비 네이터에 비해 몇 가지 장점이 있습니다. 예를 들어 수익률 포인트에서 차용을 지원합니다.

콤비 네이터는 async / await 오래 전에 존재했지만, 어쨌든 async / await가 발명되었고 그럴만 한 이유가 있습니다!

Async / await는 여기에 남아 있으므로 인체 공학적이어야합니다 (메서드 체인 포함).

물론 사람들은 원하는 경우 콤비 네이터를 자유롭게 사용할 수 있지만 좋은 인체 공학을 얻기 위해 꼭 필요한 것은 아닙니다.

@cramertj가 말했듯이 토론은 async / await의 대안이 아닌 async / await에 초점을 맞추도록합시다.

실제로 실패시 백업 동작을 원하는 경우 일부 표현식은 대기 체인으로 잘 변환되지 않습니다.

예제를 크게 단순화 할 수 있습니다.

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()

이를 통해 오류를 처리하는 부분과 정상적인 행복한 경로에있는 부분이 명확 해집니다.

이것은 async / await의 가장 큰 장점 중 하나입니다 : 루프, 브랜치, match , ? , try 등 언어의 다른 부분과 잘 작동합니다.

사실 await 하고 이것은 Futures를 사용하지 않는 경우 작성하는 것과 동일한 코드입니다.

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()

그리고 가장 좋은 방법은 일반 코드를 별도의 함수로 이동하여 오류 처리 코드를 더욱 명확하게 만드는 것입니다.

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()

( @joshtriplett 의 의견에 대한 답변입니다 ).

명확하게하기 위해, 일부 사람들은 괄호없이 읽기가 너무 어렵다라고 때문에 나는 그것을 언급, 괄호로 할 필요가 없습니다. 따라서 괄호는 선택 적인 스타일 선택 사항입니다 (복잡한 한 줄짜리에만 유용함).

어떤 상황에서 괄호의 구문 혜택의 모든는 구문의 아무도 우리가에 대한 최적화를 할 경우의 질문, 완벽하지 않습니다.

또한, 귀하의 의견을 다시 읽은 후, 제가 await 접두사를 옹호한다고 생각했을 것입니다. 나는 그렇지 않았다. 내 예제는 await 접미사를 사용하고 있었다. 나는 전체적으로 await 접미사를 좋아하지만 다른 구문도 좋아합니다.

저는 fut.await 에 익숙해지기 시작했습니다. 사람들의 초기 반응은 "잠깐, 그게 당신이 기다릴 때까지 기다리세요? 이상 해요."라고 생각합니다. 그러나 나중에 그들은 편의를 위해 그것을 좋아할 것입니다. 물론, 같은 마찬가지입니다 @await 더 이상 눈에 띄는, .await .

이 구문을 사용하면 예제에서 몇 가지 let을 생략 할 수 있습니다.

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()

이것은 또한 ? 언 래핑되는 것이 무엇인지 더 명확하게합니다. await some_op()? 의 경우 some_op() 이 언 래핑되는지 또는 기다린 결과인지 명확하지 않습니다.

파우 안

저는 여기서 주제에서 초점을 옮기려는 것이 아니라 그것이 거품 속에 존재하지 않는다는 점을 지적하려고합니다. 우리는 어떻게 함께 작동하는지 고려해야합니다.

이상적인 구문을 선택 했더라도 어떤 상황에서는 커스텀 퓨처와 결합자를 사용하고 싶습니다. 소프트 사용되지 않을 수 있다는 생각은 Rust의 전체 방향에 의문을 제기합니다.

제공하는 예제는 결합 자에 비해 여전히 끔찍해 보이며 생성기 오버 헤드로 인해 아마도 약간 느리고 더 많은 기계 코드를 생성 할 것입니다.

기다리는 한,이 모든 접두사 / 접미사시길 / 키워드 자전거 쉐딩은 훌륭하지만 아마도 우리는 실용적이고 Rust에 오는 사용자에게 가장 친숙한 가장 간단한 옵션을 사용해야합니다. IE : 접두사 키워드

올해는 우리가 생각하는 것보다 더 빨리 갈 것입니다. 1 월도 대부분 끝납니다. 사용자가 접두사 키워드에 만족하지 않는다는 것이 밝혀지면 2019/2020 에디션에서 변경할 수 있습니다. 우리는 "돌아온 것은 2020 년이다"라는 농담을 할 수도 있습니다.

헉헉

제가 본 일반적인 합의는 우리가 제 3 판을 원할 _ 가장 이른 _ 것은 2022 년이라는 것입니다. 우리는 분명히 다른 판을 계획하고 싶지 않습니다. 2018 년판은 훌륭했지만 비용이 들지 않았습니다. (2018 년 에디션의 요점 중 하나는 async / await를 가능하게하는 것입니다. 다시 가져 와서 "아니요, 지금 2020 년 에디션으로 업그레이드해야합니다!"라고 상상해보세요.)

어쨌든 나는 그것이 바람직 할지라도 에디션에서 접두어 키워드-> 접두어 키워드 전환이 가능하다고 생각하지 않습니다. 에디션에 대한 규칙은 에디션 X에서 경고없이 컴파일되고 에디션 X + 1에서 동일하게 작동하도록 관용적 코드를 작성하는 방법이 있어야한다는 것입니다.

다른 솔루션에 대한 합의를 이끌어 낼 수 있다면 키워드 매크로로 안정화하지 않으려는 것도 같은 이유입니다. 바람직하지 않다는 것을 알고있는 솔루션을 고의적으로 안정화하는 것 자체가 문제입니다.

대기 지점이 하나 뿐인 식의 경우에도 접미사 솔루션이 더 최적임을 보여준 것 같습니다. 그러나 제안 된 접미사 솔루션이 다른 모든 솔루션보다 분명히 낫다고 생각하지 않습니다.

내 2 센트 만 (나는 아무도 아니지만 꽤 오랫동안 토론을 따릅니다). 내가 가장 좋아하는 솔루션은 @await postfix 버전입니다. 새로운 접미사 매크로 구문과 같은 접미사 !await 고려할 수 있습니까?

예:

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

몇 번의 언어 반복 후에 우리 자신의 접미사 매크로를 구현할 수 있다는 것은 대단 할 것입니다.

... 모든 새로운 sygils 제안

Rust는 이미 구문 / sygil 무겁고, await 키워드가 예약되어 있고, stuff@await (또는 다른 모든 sygil)이 이상하고 못 생겼습니다 (주관적입니다). 큰 위험 신호 인 언어의 다른 어떤 것과도 통합되지 않습니다.

Go가 어떻게 구현하는지 살펴 보았습니다.
... <-... 제안

@ I60R : Go는 임시 솔루션으로 가득 찬 끔찍한 구문을 가지고 있으며 Rust와는 달리 완전히 필수입니다. 이 제안은 다시 sygil / syntax 무겁고이 특정 기능에 대해 완전히 임시적입니다.

@ I60R : Go에는 끔찍한 구문이 있습니다.

여기서 다른 언어를 강타하지 않도록합시다. "X는 끔찍한 구문을 가지고 있습니다"는 깨달음과 합의로 이어지지 않습니다.

Python / JavaScript / Rust 사용자이자 컴퓨터 과학 학생으로서 저는 개인적으로 접두어 await + f.await() 둘 다 언어로 사용하는 것을 선호합니다.

1. Python과 JavaScript 모두 접두사 await 있습니다. 처음에 await 나타날 것으로 예상합니다. 이것이 비동기 코드라는 것을 깨닫기 위해 줄을 깊숙이 읽어야한다면 매우 불안합니다. Rust의 WASM 기능으로 많은 JS 개발자를 끌어들일 수 있습니다. Rust가 이미 많은 새로운 개념을 가지고 있다는 점을 고려할 때 친숙 함 과 편안함 이 정말 중요하다고 생각합니다.

2. 접미사 await 는 연결 설정에서 편리해 보입니다. 그러나 .await , @await , f await 같은 솔루션은 await 구문에 대한 임시 솔루션처럼 보이지만 .await() 에서 future 의 메서드를 호출합니다.

Rust는 이미 자바 스크립트에서 벗어 났고 await는 await를 나타내는 함수를 사용하여 함수를 호출하는 것과는 전혀 다릅니다 (즉, 함수를 통해 기능을 에뮬레이션 할 수 없음). 따라서 구문이 달라야한다고 생각합니다.

나는 .await() 이 아마도 .await 보다 훨씬 더 바람직하다고 확신했지만,이 포스트의 나머지 부분은 그 포지션을 약간 헤지하고 있습니다.

그 이유는 await!(fut) 이 _ 가치로 fut 를 소비해야하기 때문입니다 _. 필드 액세스처럼 보이게하는 것은 _bad_입니다. 왜냐하면 접두어 키워드가하는 방식으로 이동한다는 의미 나 매크로 나 메서드 호출처럼 이동할 가능성이 없기 때문입니다.

흥미롭게도 키워드 메서드 구문은 거의 암시 적 대기 디자인처럼 보입니다. 안타깝게도 "명시 적 비동기, 암시 적 대기"는 Rust에 대해 불가능합니다 (따라서이 스레드에서 다시 소송을 제기하지 마십시오). async fn() -> T 이 fn() -> Future<T> 와 동일하게 사용되기를 원하기 때문입니다. "암시 적 대기"동작을 활성화하는 것보다

.await() 구문이 암시 적 대기 시스템 (예 : Kotlin 사용)처럼 _looks_한다는 사실은 비방을 유발할 수 있으며, 그렇지 않은 경우에 대한 마법으로 인해 거의 "암시 적 비동기, 암시 적 대기"의 느낌을 줄 것입니다. really-a-method-call .await() 구문. UFCS에서 await(fut) 로 사용할 수 있습니까? UFCS의 경우 Future::await(fut) 입니까? 언어의 다른 차원처럼 보이는 모든 구문은 기능적으로는 아니지만 적어도 구문 적으로 통일 될 수 없다면 문제를 일으 킵니다.

접두사 솔루션의 개념이 일반적으로 접두사보다 더 바람직하지만 _individual_ postfix 솔루션의 이점이 동일한 솔루션의 단점을 능가하는 경우 회의적입니다.

이 스레드가 초기 제안에 비해 상당한 이점을 제공하는 것처럼 보이는 것이 아니라 가능하기 때문에 만들어진 제안으로 가득 차 있다는 사실에 약간 놀랐습니다.
$ , # , @ , ! , ~ 등에 대해 중요한 논거없이 무엇이 잘못되었는지 그만 둘 수 있을까요? await 으로 잘 이해되고 다양한 다른 프로그래밍 언어에서 입증 되었습니까?

https://github.com/rust-lang/rust/issues/57640#issuecomment -455361619의 게시물에 이미 모든 좋은 옵션이 나열되어 있다고 생각합니다.

그로부터 :

• 필수 구분 기호 구분 기호는 괜찮아 보이지만 적어도 우선 순위가 무엇인지는 분명하며 더 명확하지 않고 다른 코드를 읽을 수 있습니다. 그리고 두 개의 괄호를 입력하는 것은 그렇게 나쁘지 않습니다. 유일한 단점은 제어 흐름 작업이 다르더라도 함수 호출처럼 보인다는 것입니다.
• 유용한 우선 순위가 바람직한 옵션 일 수 있습니다. 그것은 대부분의 다른 언어가 갔던 길인 것처럼 보이므로 친숙하고 입증되었습니다.
• 개인적으로 공백이있는 접미사 키워드가 하나의 문에서 여러 번 대기하는 것이 이상해 보인다고 생각합니다.
  client.get("url").send() await?.json()? 그 사이의 공백은 제자리에서 보이지 않습니다. 괄호를 사용하면 (client.get("url").send() await)?.json()? 가 좀 더 의미가 있습니다.
  그러나 제어 흐름은 접두사 변형보다 따르기가 여전히 더 어렵다는 것을 알았습니다.
• 나는 접미사 필드를 좋아하지 않습니다. await 은 매우 복잡한 작업을 수행합니다. Rust에는 계산 가능한 속성이 없으며 필드 액세스는 매우 간단한 작업입니다. 따라서이 작업의 복잡성에 대해 잘못된 인상을주는 것 같습니다.
• Postfix 방법은 괜찮을 수 있습니다. 일부 사람들이 여러 개의 awaits가있는 매우 긴 문장을 작성하도록 장려하여 수익률 포인트를 더 숨길 수 있습니다. 또한 뭔가 다르더라도 다시 메서드 호출처럼 보이게 만듭니다.

이러한 이유로 저는 "유용한 우선 순위"다음에 "필수 구분 기호"를 선호합니다.

Go는 임시 솔루션으로 가득 찬 끔찍한 구문을 가지고 있으며 Rust와는 달리 완전히 필수입니다. 이 제안은 다시 sygil / syntax 무겁고이 특정 기능에 대해 완전히 임시적입니다.

@dpc , <-- 제안서를 완전히 읽으면이 구문은 Go에서만 영감을 얻었지만 명령형 및 함수 체인 컨텍스트에서 상당히 다르며 사용할 수 있습니다. 나는 또한 await 구문이 임시 솔루션이 아닌 방법을 보지 못합니다. 저에게는 <-- 보다 훨씬 더 구체적이고 어설픈 방법입니다. *reference 대신 deref reference / reference.deref / etc를 사용하거나 result? 대신 try result / result.try / etc를 사용하는 것과 유사합니다 *reference result? . 어쨌든 일관성 있고 구성 가능한 구문을 갖는 것보다 덜 중요해야하는 JS / Python / etc에 익숙한 것 외에는 await 키워드를 사용하는 것의 이점이 없습니다. 그리고 <-- 시길을 사용하는 것의 단점은 await 가 아니라는 점을 제외하고는 볼 수 없습니다. 어쨌든 평범한 영어만큼 간단하지 않으며 사용자는 먼저 무엇을하는지 이해해야합니다.

편집 : 이것은 await 에 대한 몇 가지 주장을 제공하고 동일한 문제로 영향을받지 않는 가능한 대안을 제안하기 때문에 @ Matthias247 게시물에 대한 좋은 답변이 될 수 있습니다.

역사적 이유와 편견에 호소하는 주장이없는 <-- 구문에 대한 비판을 읽는 것은 정말 흥미 롭습니다.

우선 순위에 대한 실제 세부 사항을 언급하겠습니다.

오늘날 의 우선 순위 차트 :

연산자 / 표현 | 연관성
-| -
경로 |
메서드 호출 |
필드 표현식 | 왼쪽에서 오른쪽으로
함수 호출, 배열 인덱싱 |
? |
단항 - * ! & &mut |
as | 왼쪽에서 오른쪽으로
* / % | 왼쪽에서 오른쪽으로
+ - | 왼쪽에서 오른쪽으로
<< >> | 왼쪽에서 오른쪽으로
& | 왼쪽에서 오른쪽으로
^ | 왼쪽에서 오른쪽으로
\| | 왼쪽에서 오른쪽으로
== != < > <= >= | 괄호 필요
&& | 왼쪽에서 오른쪽으로
\|\| | 왼쪽에서 오른쪽으로
.. ..= | 괄호 필요
= += -= *= /= %= &= \|= ^= <<= >>= | 오른쪽에서 왼쪽으로
return break 폐쇄 |

유용한 우선 순위는 await 앞에 ? 두어 ? 보다 더 단단히 바인딩합니다. 따라서 체인의 ? 는`await를 이전의 모든 것에 바인딩합니다.

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

예, 유용한 우선 순위로 "그냥 작동"합니다. 그게 뭔지 한 눈에 알아? (아마도) 나쁜 스타일인가요? 그렇다면 rustfmt가 자동으로 수정할 수 있습니까?

명백한 우선 순위는 await _somewhere_를 ? 아래에 둡니다. 그 세부 사항은 아마도별로 중요하지 않지만 정확히 어디에 있는지 모르겠습니다.

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

그게 뭔지 한 눈에 알아? rustfmt는 자동으로 수직 및 수평 공간을 낭비하지 않는 유용한 스타일로 만들 수 있습니까?

접미사 키워드는 어디에 속합니까? 아마도 메서드 호출이있는 키워드 메서드와 필드식이있는 키워드 필드 일 것입니다.하지만 다른 사람들이 어떻게 바인딩해야하는지 잘 모르겠습니다. await 가 놀라운 "인수"를받는 상황에서 가능한 최소 구성으로 이어지는 옵션은 무엇입니까?

이 비교를 위해 "필수 구분 기호"( 요약 에서 키워드 함수라고 부른

@ CAD97 명확하게 .json() 도 미래라는 것을 기억하십시오 (적어도 reqwests ).

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

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

내가 더 복잡한 녹 표현으로 변환하여 재생 (1 await를 만 필요로 심지어 사람을하지만, 내 20,000 미래의 코드베이스에 거의 모든 단일 비동기 식을 직접 다른 await를 뒤에 기다리고 있습니다 것을 주), 더 내가 싫어 Rust의 접두사.

? 연산자 때문에 _all_입니다. 다른 언어에는 기본적으로 항상 실제 코드에서 쌍을 이루는 접미사 제어 흐름 연산자 _and_ await 가 없습니다.

내 선호는 여전히 postfix 필드 입니다. 접미사 제어 연산자로서 future.await 가 future await 이상 제공하는 엄격한 시각적 그룹화가 필요하다고 생각합니다. 그리고 .await()? 과 비교하면 .await? _weird_ 방식을 선호하므로 _noticed_하고 사용자는 단순한 기능이라고 생각하지 않을 것입니다 (따라서 UFCS가 작동하지 않는 이유를 묻지 않습니다). .

이 안정되어 후위에 찬성 하나 이상의 데이터 포인트와 같은 rustfix 에서 이동합니다 await!(...) 우리는 매우 극명하게 될 것이다 결정 무엇 이건. 필자는 ( ... ) 불필요하게 항목을 래핑하지 않고 접미사 구문을 모호하지 않게 번역 할 수있는 방법을 알 수 없습니다.

먼저 "연쇄 컨텍스트에서 await 사용을 권장합니까?"라는 질문에 답해야한다고 생각합니다. 나는 일반적인 대답이 "예"라고 믿기 때문에 후위 변형에 대한 강력한 주장이됩니다. await!(..) 이 가장 쉽게 추가 할 수 있지만 try!(..) 이야기를 반복해서는 안됩니다. 또한 나는 개인적으로 "체인은 잠재적으로 비용이 많이 드는 작업을 숨긴다"는 주장에 동의하지 않습니다. 우리는 이미 _ 매우 _ 무거울 수있는 많은 연결 방법을 가지고 있으므로 연결은 게으름을 수반하지 않습니다.

접두사 await 키워드는 다른 언어를 사용하는 사용자에게 가장 친숙한 키워드이지만이를 기반으로 결정을 내리지 않고 대신 사용성, 편의성 및 가독성과 같은 장기에 집중해야한다고 생각합니다. . @withoutboats 는 "익숙한 예산"에

이제 우리는 아마도 같은 일을하는 두 가지 방법을 원하지 않을 것이므로 접미사와 접두사 변형을 모두 도입해서는 안됩니다. 따라서 옵션을 접미사 변형으로 좁혔다 고 가정 해 보겠습니다.

먼저 fut await 시작하겠습니다.이 변형은 사람이 코드를 구문 분석하는 방법을 심각하게 엉망으로 만들고 코드를 읽는 동안 지속적인 혼란의 원인이 될 것이기 때문에이 변형을 매우 싫어합니다. (코드는 대부분 읽기 용이라는 것을 잊지 마십시오)

다음 fut.await , fut.await() 및 fut.await!() . 가장 일관되고 덜 혼란스러운 변형은 접미사 매크로 일 것입니다. 몇 개의 문자를 저장하기 위해 새로운 "키워드 기능"또는 "키워드 방법"엔티티를 도입하는 것은 가치가 없다고 생각합니다.

마지막으로시길 기반 변형 : fut@await 및 fut@ . fut@await 변형이 마음에 들지 않습니다.시길을 소개하면 await 부분이 왜 귀찮을까요? 향후 확장 fut@something 대한 계획이 있습니까? 그렇지 않다면 단순히 중복 된 것처럼 느껴집니다. 그래서 저는 fut@ 변형을 좋아하고 우선 순위 문제를 해결하고 코드를 이해하고, 쓰고, 읽기 쉽게 만듭니다. 가시성 문제는 코드 강조 표시로 해결할 수 있습니다. 이 기능을 "@ for await"로 설명하는 것은 어렵지 않습니다. 물론 가장 큰 단점은 매우 제한된 "시길 예산"으로이 기능에 대해 비용을 지불한다는 것입니다.하지만 기능의 중요성과 비동기 코드베이스에서 얼마나 자주 사용되는지를 고려할 때 장기적으로 가치가 있다고 생각합니다. . 그리고 물론 우리는 ? 로 특정 유사점을 그릴 수 있습니다. (우리는 Rust 비평가들의 Perl 농담에 대비해야합니다.)

결론 : 내 의견으로는 "시길 예산"을 부담 할 준비가 되었으면 fut@ 를 사용하고 그렇지 않은 경우 fut.await!() 합니다.

친숙함에 대해 이야기 할 때, Rust는 다른 틈새 시장에 있고 이미 많은면에서 다르게 보이기 때문에 JS / Python / C #에 대한 친숙함에 너무 신경을 써야한다고 생각하지 않습니다. 이러한 언어와 유사한 구문을 제공하는 것은 단기적이고 낮은 보상 목표입니다. 후드 아래에서 완전히 다르게 작동 할 때 익숙한 키워드를 사용하기 위해서만 Rust를 선택하는 사람은 없습니다.

하지만 Go에 대한 친숙 함은 중요합니다. Rust는 비슷한 틈새 시장에 있고 철학적으로도 다른 언어보다 Go에 더 가깝기 때문입니다. 그리고 모든 편견에 찬 증오에도 불구하고, 둘 다의 가장 큰 장점 중 하나는 기능을 맹목적으로 복사하지 않고 대신 진정 이유가있는 솔루션을 구현한다는 것입니다.

IMO, 이런 의미에서 <-- 구문이 가장 강력합니다.

이 모든 것을 가지고 Rust 표현식이 여러 개의 연결 메서드를 생성 할 수 있음을 기억합시다. 대부분의 언어는 그렇게하지 않는 경향이 있습니다.

C # 개발 팀 경험을 상기시키고 싶습니다.

C # 구문에 대한 주요 고려 사항은 연산자 우선 순위 await foo?

이것은 제가 언급 할 수있는 것 같은 느낌입니다. 'await'로 우선 순위를 많이 고민했고 원하는 형태를 설정하기 전에 여러 형태를 시도 해봤습니다. 우리가 발견 한 핵심 사항 중 하나는 우리와이 기능을 사용하기를 원하는 고객 (내부 및 외부)에게, 사람들이 비동기 호출 이후의 모든 것을 실제로 '체인'하고 싶어하는 경우는 드물다는 것입니다.

expr 내부에서 'await'로 '계속'하려는 사람들의 경향은 드뭅니다. 때때로 (await expr) .M ()과 같은 것을 보지만, await expr.M ()을하는 사람들의 양보다 덜 일반적이고 덜 바람직해 보입니다.

과

이것이 우리가 'await'에 대해 '암시 적'형식을 사용하지 않은 이유이기도합니다. 실제로는 사람들이 매우 명확하게 생각하기를 원했고, 코드에주의를 기울일 수 있도록 코드의 전면 중앙을 원했습니다. 흥미롭게도, 심지어 몇 년이 지난 후에도 이러한 경향은 여전히 ​​남아 있습니다. 즉, 때때로 우리는 무언가가 지나치게 장황한 것을 몇 년 후 후회합니다. 초기에는 일부 기능이 좋지만 사람들이 익숙해지면 더 간결한 것에 더 적합합니다. 'await'는 그렇지 않습니다 . 사람들은 여전히 ​​그 키워드의 무거운 특성과 우리가 선택한 우선 순위를 정말 좋아하는 것 같습니다.

전용 (키) 단어 대신시길에 대한 좋은 점입니다.

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

수백만 명의 사용자가있는 사람들의 말을 정말로 들어야합니다.

그래서 당신은 어떤 것도 연결하고 싶지 않고 await 여러 개를 원하며 내 경험은 동일합니다. 6 년 넘게 async/await 코드를 작성했는데 그런 기능을 원하지 않았습니다. Postfix 구문은 정말 낯설어 보이며 결코 발생하지 않을 상황을 해결하는 것으로 간주됩니다. Async 통화는 정말 대담한 것이므로 한 줄로 여러 번 기다리는 것은 너무 무겁습니다.

expr 내부에서 'await'로 '계속'하려는 사람들의 경향은 드뭅니다. 때때로 (await expr) .M ()과 같은 것을 보지만, await expr.M ()을하는 사람들의 양보다 덜 일반적이고 덜 바람직해 보입니다.

그것은 사후 분석처럼 보입니다. 그들이 계속하지 않는 이유 중 하나는 접두사 구문에서 그렇게하는 것이 매우 어색하기 때문일 수 있습니다 ( ? 연산자를 통해 읽을 수 있기 때문에 문에서 try! 여러 번 원하지 않는 것과 비교할 수 있습니다. ? ). 위의 내용은 대부분 위치가 아닌 우선 순위를 고려합니다. 그리고 C #은 Rust가 아니며, 트레이 트 멤버는 결과에 대해 메서드를 호출하려는 욕구를 상당히 변경할 수 있음을 상기시키고 싶습니다.

@ I60R ,

1. 친숙 함이 중요하다고 생각합니다. Rust는 비교적 새로운 언어이며 사람들은 다른 언어에서 이주 할 것이며 Rust가 친숙해 보이면 Rust를 선택하는 것이 더 쉬울 것입니다.
2. 나는 연결 메서드를 크게 재미하지 않습니다. 긴 체인을 디버그하는 것이 훨씬 더 어렵고 코드 가독성을 복잡하게 만들고 추가 옵션으로 만 허용 될 수 있습니다 (매크로 .await!() ). 접두사 형식은 개발자가 다음과 같이 체인 대신 메서드로 코드를 추출하도록합니다.

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

다음과 같이 :

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

그것은 사후 분석처럼 보입니다. 그들이 계속하지 않는 이유 중 하나는 접두사 구문에서 그렇게하는 것이 매우 어색하기 때문일 수 있습니다. 위의 내용은 위치가 아닌 우선 순위만을 고려합니다. 그리고 C #은 Rust가 아니며, 트레이 트 멤버는 결과에 대해 메서드를 호출하려는 욕구를 상당히 변경할 수 있음을 상기시키고 싶습니다.

아니요, 접두사 / 접미사 / 암시 적 형식이 모두있는 경우 내부 C # 팀 실험에 관한 것입니다. 그리고 저는 접미사 형태 전문가를 볼 수없는 습관이 아닌 제 경험에 대해 이야기하고 있습니다.

@mehcode 귀하의 예는 저에게 동기를 부여하지 않습니다. reqwest 의식적으로 초기 요청 / 응답주기와 응답 (본문 스트림)의 후속 처리를 별도의 동시 프로세스로 만들기로 결정하므로 @andreytkachenko가 보여준 것처럼 두 번 기다려야합니다.

reqwest 는 다음 API를 완전히 노출 할 수 있습니다.

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

또는

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

(후자는 and_then 이상의 단순 설탕입니다).

reqwest s 및 hyper s와 hyper 의 최상의 API 결정은 이러한 사항을 별도로 유지하는 것이므로 여기에있는 많은 접미사 예제에서이 체인을 예로 사용하는 것이 문제가됩니다.

나는 정직하게 대부분의 postfix await 예제는 결합자를 사용하여 다시 작성하거나 (필요한 경우 설탕) 유사한 작업을 유지하고 여러 번 기다려야한다고 믿습니다.

안녕하세요.

접두사 형식은 개발자가 다음과 같이 연결하는 대신 메서드로 코드를 추출하도록합니다.

그것은 좋은 것입니까, 나쁜 것입니까? M 개의 후속 조치로 이어질 수있는 N 개의 메서드가있는 경우 개발자는 N * M 메서드를 제공해야합니까? 개인적으로 구성 가능한 솔루션은 조금 더 길더라도 좋아합니다.

다음과 같이 :

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

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

헉

나는 C #에서 Rust 에서처럼 체인 / 기능적 코드를 많이 얻을 것이라고 생각하지 않습니다. 아니면 내가 틀렸나 요? 이는 C # 개발자 / 사용자의 경험을 흥미롭게하지만 Rust에 반드시 적용 할 수있는 것은 아닙니다. 나는 우리가 Ocaml 또는 Haskell과 대조 될 수 있기를 바랍니다.

불일치의 근본 원인은 우리 중 일부는 명령형 스타일을 즐기고 일부는 기능적 스타일을 즐긴다는 것입니다. 그리고 그게 다야. Rust는 둘 다 지원하며 논쟁의 양측은 일반적으로 코드를 작성하는 방식에 비동기가 잘 맞기를 원합니다.

@dpc

나는 C #에서 Rust 에서처럼 체인 / 기능적 코드를 많이 얻을 것이라고 생각하지 않습니다. 아니면 내가 틀렸나 요? 이는 C # 개발자 / 사용자의 경험을 흥미롭게하지만 Rust에 반드시 적용 할 수있는 것은 아닙니다. 나는 우리가 Ocaml 또는 Haskell과 대조 될 수 있기를 바랍니다.

LINQ 및 기능적 스타일은 C #에서 매우 인기 가 있습니다.

@dpc ,
가독성에 관한 것이라면-나는 명시적인 코드만큼이나 좋다고 생각하며, 내 경험에 따르면 메서드 / 함수 이름이 자체 설명이 잘되어 있으면 후속 조치를 수행 할 필요가 없다고합니다.

오버 헤드에 대해서-Rust 컴파일러는 그것들을 인라인하는 것이 현명합니다 (어쨌든 우리는 항상 #[inline] ).

@dpc

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

내 느낌은 이것이 기본적으로 futures API의 문제를 반복한다는 것입니다. 연결이 더 쉬워 지지만 해당 체인의 유형은 침투 및 디버그가 훨씬 더 어려워집니다.

동일한 주장이?에 적용되지 않습니까? 운영자? 더 많은 체인을 허용하므로 디버깅이 더 어려워집니다. 하지만 우리가 선택한 이유는 무엇입니까? 시도 이상! 그때? 그리고 Rust는 왜 빌더 패턴이있는 API를 선호합니까? 따라서 Rust는 이미 API에서 체인을 선호하는 많은 선택을했습니다. 그리고 네, 디버깅이 더 어려워 질 수 있지만 린트 수준에서 발생해서는 안됩니다. 너무 큰 체인에 대한 새로운 린트 일 수도 있습니다. 나는 여기서 기다리는 것이 어떻게 다른지에 대한 충분한 동기를 봐야합니다.

그것은 좋은 것입니까, 나쁜 것입니까? M 개의 후속 조치로 이어질 수있는 N 개의 메서드가있는 경우 개발자는 N * M 메서드를 제공해야합니까? 개인적으로 구성 가능한 솔루션은 조금 더 길더라도 좋아합니다.

N과 M은 반드시 크지 않으며 모두가 추출에 흥미 롭거나 유용하지 않을 수 있습니다.

@andreytkachenko ,

1. 동의하지 않습니다. 친숙 함이 여기에서 과대 평가됩니다. 다른 언어에서 마이그레이션 할 때 먼저 사람들은 async-await 스타일의 프로그래밍을 수행 할 수있는 능력을 추구하지만 정확히 동일한 구문을 사용하지는 않습니다. 다르게 구현되지만 더 나은 프로그래밍 경험을 제공한다면 또 다른 이점이 될 것입니다.

2. 긴 체인을 디버깅 할 수 없다는 것은 코드 스타일이 아닌 디버거의 한계입니다. 가독성에 대해서는 상황에 따라 다르며 명령형 스타일을 적용하는 것은 여기서 불필요하게 제한적이라고 생각합니다. async 함수 호출이 여전히 함수 호출 인 경우 연결을 지원하지 않는 것이 놀랍습니다. 어쨌든 <-- 는 말했듯이 함수 체인에서 추가 옵션으로 사용할 수있는 접두사 연산자입니다.

@skade 동의합니다.

기다림 체인이 긴 모든 예제는 코드 냄새입니다. 이러한 생성기 스파게티 상태 머신을 내부적으로 생성하는 대신 결합 자 또는 업데이트 된 API를 사용하여 훨씬 더 우아하게 해결할 수 있습니다. 극단적 인 속기 구문은 현재 미래보다 훨씬 더 어려운 디버깅을위한 레시피입니다.

나는 아직도의 팬입니다 모두 접두사 키워드 await 매크로 await!(...) / .await!() ,와 함께 async 및 #[async] 생성 기능 , 여기 에 내 의견에 설명되어 있습니다.

모든 것이 올바르게 진행되면 접두사와 접미사를 모두 처리하기 위해 await! 에 대해 단일 매크로를 만들 수 있으며 await 키워드는 async 함수 내의 키워드 일뿐입니다.

@skade ,
나에게 future 에서 결합자를 사용할 때의 큰 단점은 async 함수 호출을 숨기고 일반 함수와 구분하는 것이 불가능하다는 것입니다. 빌더 스타일 체인 내부에서 사용될 가능성이 매우 높기 때문에 모든 일시 중단 가능한 포인트를보고 싶습니다.

@ I60R 긴 콜 체인을 디버깅하는 것은 디버거 문제가 아닙니다. 이러한 메소드 중 다수가 일반 매개 변수를 취하고 잠재적으로 클로저에 바인딩 된 일반 매개 변수를 전달한다는 점을 감안할 때 심각한 문제입니다.

모든 정지 지점을 표시하는 것이이 기능의 목표인지 확실하지 않습니다. 이것은 구현자가 결정할 문제입니다. 그리고 제안 된 await 구문의 모든 버전에서 완전히 가능합니다.

@novacrazy 좋은 지적, 이제 당신이 그것을 언급

다음과 같이 보일 것 같아요

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

가능한지 모르겠지만 Rust에서 퓨처를 찾아봐야합니다.

@richardanaya 이것은 완전히 가능합니다 (다른 구문).

Box impl처럼 :

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

다음과 같이 새 키워드 await 하고 Await 특성을 입력 할 수 있습니다.

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

그리고 await 를 메소드와 키워드로 사용하십시오.

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

@richardanaya 동의합니다. 저는 수년 전에 제 webdev에 async / await를 채택한 최초의 개발자 중 일부였으며, 진정한 힘 은 async / await를 기존 Promise / Futures와

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

let value = result.unwrap();

중첩 된 선물이나 선물의 결과 또는 결과의 미래가있는 경우 .flatten() 결합기는이를 대폭 단순화 할 수 있습니다. 수동으로 모든 것을 풀고 기다리는 것은 나쁜 형태입니다.

@XX 중복되고 유효하지 않습니다. await 는 async 함수에만 존재하며 Future / IntoFuture 을 (를) 구현하는 유형에서만 작동 할 수 있으므로 새로 추가 할 필요가 없습니다. 특성.

@novacrazy , @richardanaya

이러한 생성기 스파게티 상태 머신을 내부에 생성하는 것보다 결합 자 또는 업데이트 된 API를 사용하여 훨씬 더 우아하게 해결할 수 있습니다. 극단적 인 속기 구문은 현재 미래보다 훨씬 더 어려운 디버깅을위한 레시피입니다.

@novacrazy 좋은 지적, 이제 당신이 그것을 언급

Combinator는 Rusts async / await에서 완전히 다른 속성과 능력을 가지고 있습니다. 비동기 블록과 동일한 기능을 가진 결합자를 안전하게 작성할 수 없습니다. 콤비 네이터 토론은 도움이되지 않으므로이 스레드에서 제외하겠습니다.

@ I60R

나에게 미래에 결합자를 사용하는 큰 단점은 비동기 함수 호출을 숨기고 정규 함수와 구별하는 것이 불가능하다는 것입니다. 빌더 스타일 체인 내부에서 사용될 가능성이 매우 높기 때문에 모든 일시 중단 가능한 포인트를보고 싶습니다.

일시 중단 지점을 숨길 수 없습니다. 결합자가 허용하는 유일한 것은 다른 미래를 만드는 것입니다. 어떤 시점에서 그것들은 기다려야합니다.

C #에는 접두사 await 를 사용하는 대부분의 코드가 (이미 존재하는) 접미사 ? 연산자와 결합되는 문제가 없습니다. 특히, 우선 순위에 대한 질문과 두 개의 유사한 "장식 자"를 갖는 일반적인 어색함이 표현의 반대편에 나타납니다.

@ Matthias247 데이터를 빌려야하는 경우에는 여러 개의 await 문을 자유롭게 사용하십시오. 그러나 종종 단순히 데이터를 이동해야하는 경우가 있으며 결합자는이를 위해 완벽하게 유효하며보다 효율적인 코드로 컴파일 할 가능성이 있습니다. 때로는 완전히 최적화됩니다.

다시 말하지만, 진정한 힘은 사물을 결합하는 것입니다. 이렇게 복잡한 일을하는 올바른 방법은 없습니다. 그것이 부분적으로 제가이 모든 구문 바이크 쉐딩을 다른 언어에서 온 새로운 사용자를 돕지 않고 유지 보수 가능하고 성능이 뛰어나며 읽기 쉬운 코드를 만드는 데 도움이되지 않는다고 생각하는 이유입니다. 80 %의 경우 구문이 무엇이든간에 async / await 건드리지 않을 것이라고 생각합니다. 단순한 미래를 사용하여 가장 안정적이고 성능이 좋은 API를 제공하기 위해서입니다.

이와 관련하여 접두어 키워드 await 및 / 또는 혼합 매크로 await!(...) / .await!() 가 가장 읽기 쉽고 친숙하며 디버그하기 쉬운 옵션입니다.

안녕하세요.

귀하의 게시물을 보았고 실제로 "익숙 함"에 대해 반성 했으므로 전적으로 동의합니다. 두 가지 유형의 친숙 함이 있다고 생각합니다.

1. await 구문을 await를 많이 사용하는 유사한 언어처럼 보이게합니다. Javascript는 여기에서 꽤 크고 커뮤니티로서의 WASM 기능과 매우 관련이 있습니다.

2. 두 번째 유형의 친숙 함은 동기 코드로만 작업하는 개발자에게 코드를 친숙하게 만드는 것입니다. await의 가장 큰 측면은 비동기 코드를 동기식으로 만드는 것입니다. 이것은 실제로 자바 스크립트가 실제로 잘못하는 한 가지는 주로 동기식 개발자에게 완전히 이질적으로 보이는 체인보다 길다는 것입니다.

자바 스크립트 비동기 시절에 제가 제공 한 한 가지는, 회고에서 개발자로서 저에게 훨씬 더 유용했던 것은 약속 / 미래를 함께 그룹화하는 기능이었습니다. Promise.all (p1 (), p2 ()) 그래서 나는 쉽게 작업을 병렬화 할 수있었습니다. then () 체이닝은 항상 자바 스크립트의 과거 약속의 반향 일 뿐이었지만, 지금은 생각해 보면 거의 구식이고 불필요합니다.

이 아이디어를 기다릴 것입니다. "비동기 코드와 동기화 코드의 차이를 최대한 최소화하십시오."

@novacrazy 비동기 함수는 impl Future 유형을 반환합니다. Future 트레이 트에 await 메서드를 추가하지 못하게하는 이유는 무엇입니까? 이 같이 :

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

@XX 내가 이해했듯이 Rust의 async 함수는 생성기를 사용하여 상태 머신으로 변환됩니다. 이 기사 는 좋은 설명입니다. 그래서 await 필요 async 컴파일러는 정확하게 모두를 변환 할 수 있도록, 직장에 기능을. await 는 async 부분 없이는 작동 할 수 없습니다.

Future 에는 제안한 것과 유사한 wait 메서드가 있지만 현재 스레드를 차단합니다.

@skade ,

그러나 코드 스타일이 유형 추론에 어떤 영향을 미칠 수 있습니까? 체인 및 명령형으로 작성된 동일한 코드에서 차이점을 볼 수 없습니다. 유형은 정확히 동일해야합니다. 디버거가이를 파악할 수 없다면 코드가 아닌 디버거에서 확실히 문제가됩니다.

@skade , @ Matthias247 , @XX

콤비 네이터를 사용하면 기능 체인의 시작 부분에 정확히 하나의 정지 지점이 표시됩니다. 다른 모든 것은 내부에 암시 적입니다. 그것은 암시 적으로 mut 를 취하는 것과 똑같은 문제입니다. 개인적으로 그것은 Rust에서 가장 큰 혼란의 포인트 중 하나였습니다. 일부 API는 선물을 반환하는 반면 다른 API는 선물의 결과를 반환합니다. 중단 점은 가능하면 명시 적이어야하며 적절하게 구성 가능한 구문은

@ I60R let 바인딩은 유형 추론에 대한 연결 지점이며 오류보고에 도움이됩니다.

헉헉

그래서 await는 작동하기 위해 비동기 함수가 필요합니다.

반환형으로 표현할 수 있습니까? 예를 들어 반환 유형은 impl Future + Async 대신 impl Future 입니다.

@skade 저는 항상 . 메서드 호출 구문이 정확히 동일한 목적을 제공한다고 생각합니다.

@dpc

나는 C #에서 Rust 에서처럼 체인 / 기능적 코드를 많이 얻을 것이라고 생각하지 않습니다. 아니면 내가 틀렸나 요? 이는 C # 개발자 / 사용자의 경험을 흥미롭게하지만 Rust에 반드시 적용 할 수있는 것은 아닙니다. 나는 우리가 Ocaml 또는 Haskell과 대조 될 수 있기를 바랍니다.

Rust만큼 많이 얻습니다. LINQ 코드를 보면 볼 수 있습니다.

일반적인 비동기 코드는 다음과 같습니다.

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();
    }
}

또는 더 일반적인

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

호출을 연결하지 않고 변수에 할당 한 다음 어떻게 든 사용합니다. 차용 검사기를 다룰 때 특히 그렇습니다.

하나의 상황에서 선물을 연결할 수 있다는 데 동의합니다. 통화 중에 발생할 수있는 오류를 처리하려는 경우. 예 : let a = await!(service_a)? . 이것은 접미사 대안이 더 나은 유일한 상황입니다. 여기에서 이점을 볼 수 있지만 모든 단점을 능가한다고 생각하지 않습니다.

또 다른 이유 : impl Add for MyFuture { ... } 및 let a = await a + b; 무엇입니까?

postfix await 키워드의 맥락에서 Generalized Type Ascription RFC 에 대해 상기시키고 싶습니다. 다음 코드를 허용합니다.

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

postfix await 키워드와 매우 유사합니다.

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

형식이 잘못된 경우에도 동일한 단점이 있습니다.

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

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

Type Ascription RFC의 약을 삼키면 일관성을 위해 fut await 를 삼켜야한다고 생각합니다.

BTW, 이것이 유효한 구문이라는 것을 알고 있습니까?

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

그러나 실제 코드에서는이 문제가 전혀 발생하지 않았습니다.

제가 조금 벗어나도록 허용 해주세요. @BenoitZugmeyer가 제안한대로 접미사 매크로를 제공해야한다고 생각합니다. expr!macro 또는 expr@macro 또는 expr.macro!() 있습니다. 첫 번째 옵션이 더 낫다고 생각합니다. 그것이 좋은 생각인지는 잘 모르겠지만, 우리가 접미사를 얻는 동안 임시 해결책이 아닌 일반적인 개념을 추출하고 싶다면 적어도 접미사 매크로를 잠재적 인 해결책으로 생각해야합니다.

await 를 접미사 매크로로 만들더라도 여전히 마법의 매크로 일 것입니다 (예 compile_error! ). 그러나 @jplatte 와 다른 사람들은 이미 문제가되지 않는다는 것을 확인했습니다.

우리가 그 길을 가면 어떻게해야할까요? 먼저 postfix 매크로가 어떻게 작동하는지 정확히 설정 한 다음 await 마법의 접미사 매크로로 허용 한 다음 나중에 정의 된 postfix 매크로를 허용합니다.

Lexing

렉싱 / 파싱의 경우 이것은 문제가 될 수 있습니다. expr!macro 를 보면 컴파일러는 expr! 라는 매크로가 있고 그 뒤에 잘못된 문자 macro 가 있다고 생각할 수 있습니다. 그러나 expr!macro 는 미리보기로 lex가 가능해야하며, expr 뒤에 ! 이어지고 바로 뒤에 identifier 오면 후위 매크로가됩니다. expr!macro 형식을 취할 수 있다고 가정하겠습니다.

접미사 매크로가 유용할까요?

머릿속에서 접미사 매크로에 대한 다른 사용 사례를 생각해 냈습니다. 나는 그들 모두가 사용자 정의 매크로로 구현 될 수 있다고 생각하지 않으므로이 목록이 매우 도움이되는지 확실하지 않습니다.

• stream!await_all : 스트림 대기 용
• option!or_continue : option 가 None이면 루프를 계속합니다.
• monad!bind : 이름에 바인딩하지 않고 =<<

stream!await_all

이를 통해 우리는 미래뿐만 아니라 스트림을 기다릴 수 있습니다.

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

( async -stream-esque 블록에서) 다음과 같습니다.

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

UpdateTickerAction::new(exchange_rate.value)

option!or_continue

이를 통해 옵션을 풀고 None 인 경우 루프를 계속할 수 있습니다.

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);
}

다음과 같습니다.

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

monad!bind

이것은 우리가 상당히 소박한 (즉, 표현 중심) 방식으로 모나드를 얻을 수있게합니다. Rust에는 아직 모나드와 같은 것이 없으며 Rust에 추가되는 것에 대해 판매하지 않습니다. 그럼에도 불구하고 추가 될 경우이 구문이 유용 할 수 있습니다.

여기 에서 다음을 가져

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 ++ "!")

다음과 동일합니다.

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;
}

또는 더 적은 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;
}

평가

나는 이것에 대해 매우 분열되어 있습니다. 내 두뇌의 수학자 부분은 await 대한 일반화 된 솔루션을 찾고 싶어하며 접미사 매크로가이를 달성하는 방법 일 수 있습니다. 내 두뇌의 실용적인 부분은 다음과 같이 생각합니다. 매크로 시스템이 이미 더 복잡한 것을 이해하지 못하는 언어를 만드는 이유는 무엇입니까?

그러나 ? 및 await 에서 매우 유용한 접미사 연산자의 두 가지 예가 있습니다. 내가 언급 한 것들과 비슷한 미래에 추가하고 싶은 다른 것들을 찾으면 어떨까요? 일반화했다면 자연스럽게 Rust에 추가 할 수 있습니다. 그렇지 않은 경우 매번 또 다른 구문을 만들어야하는데, 이는 접미사 매크로보다 언어를 더 부 풀릴 가능성이 높습니다.

너희들은 어떻게 생각하니?

안녕하세요.

나는 매우 유사한 아이디어를 생각 해냈고, Rust의 접미사 매크로는 시간 문제라는 것을 확신합니다.
ndarray 슬라이싱을 다룰 때마다 생각하고 있습니다.

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

그러나 훨씬 더 좋을 것입니다

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

_with 또는 _else 접미사가있는 것과 같은 많은 결합자가 사라질 수 있습니다.

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

@EyeOfPython @andreytkachenko postfix 매크로는 현재 Rust의 기능이 아니며 IMHO는 완전한 RFC + FCP + Implementation 단계가 필요합니다.

이것은 RFC 논의가 아니라 구현해야하는 승인 된 RFC에 대한 논의입니다.

그렇기 때문에 여기서 논의하거나 비동기 구문을 제안하는 것이 실용적이라고 생각하지 않습니다. 기능이 크게 지연됩니다.

이미 방대한 논의를 억제하기 위해 여기서 논의하는 것이 유용하지 _ 아닙니다 _, 논의 된 문제의 외부로 볼 수 있습니다.

몇 가지 생각 :이 스레드는 특별히 await 위한 것이지만, 앞으로 yield 표현식에 대해서도 동일한 논의가있을 것입니다. 마찬가지로 연결될 수 있습니다. 나는 일반화 할 수있는 구문을보고 싶지만,보기에는 충분합니다.

여기에 매크로를 사용하지 않는 이유 :

1. 매크로는 도메인 특정 항목에 제공되며 프로그램 제어 흐름을 변경하거나 핵심 언어 기능을 에뮬레이트하는 방식으로 매크로를 사용하는 것은 과잉입니다.
2. Postfix 매크로는 사용자 지정 연산자 또는 잘못된 코드로 이어지는 기타 비정상적인 언어 기능을 구현하기 위해 즉시 악용됩니다.
3. 적절한 언어 기능을 개발하는 것을 권장하지 않습니다.
   
   
   
   • stream.await_all 은 combinator의 완벽한 사용 사례입니다.
   
   
   • option.or_continue 및 _else 결합자를 대체하는 것은 null 병합 연산자의 완벽한 사용 사례입니다.
   
   
   • monad.bind 은 if-let 체인의 완벽한 사용 사례입니다.
   
   
   • ndarray slicing 는 const 제네릭의 완벽한 사용 사례입니다.
   
   
4. 그들은 이미 ? 연산자를 구현

안녕하세요.

마찬가지로 연결될 수 있습니다

도대체 왜 그들이 묶일 수 있다고 생각합니까? 위의 println 예제처럼 실제 코드에서 발생하지 않습니다.

@Pzixel 결국 Generator::resume 가 값을 가질 가능성이 있으므로 yield expr 은 비 () 유형을 갖게됩니다.

@vlaff 유형 Ascription과 일치해야하는 await 대한 인수가 명확하게 보이지 않습니다. 그들은 매우 다른 것들입니다.

또한 Type Ascription은 반복적으로 시도되는 기능 중 하나이며 _this_가 성공할 것이라는 보장은 없습니다. 이에 반대하고 싶지는 않지만 TA는 미래의 RFC이며 이것은 이미 제안 된 구문으로 허용되는 기능에 대한 논의입니다.

많은 주석을 읽고 왜 await! (...)가 매우 이상적인 경로로 나타나는지에 대한 추가 요약을 추가합니다.

1. 매크로가 익숙하기 때문에 기존 코드에 가장 익숙해 보입니다.
2. await! (...) https://github.com/alexcrichton/futures-await 를 사용하는 기존 작업이 있으며 코드 재 작성을 줄이는 데 도움이 될 수 있습니다.
3. 접미사 매크로는 테이블에 없기 때문에 언어의 일부가 될 수 없으며 "기다립니다!" 비표준 컨텍스트에서는 RFC에 따라 가능성조차 보이지 않습니다.
4. 그것은 완전히 표준을 벗어나지 않는 무언가를 제공하면서 광범위하게 안정적인 사용 후 장기적인 방향을 고려할 시간을 커뮤니티에 더 많이 제공합니다 (예 : try! ()).
5. await와 yield를 만족시킬 수있는 공식 경로를 찾을 때까지 다가오는 yield! ()와 유사한 패턴으로 사용할 수 있습니다.
6. 체이닝은 원하는만큼 가치가 없을 수 있으며 여러 줄에 여러 개의 대기가 있음으로써 명확성이 향상 될 수도 있습니다.
7. IDE 구문 하이 라이터에 대해서는 변경이 필요하지 않습니다.
8. 다른 언어의 사람들은 아마도 다른 매크로 사용을 본 후 await! (...) 매크로에 의해 버려지지 않을 것입니다 (인지 과부하가 적음)
9. 안정화로 나아 가기위한 모든 경로 중 가장 최소한의 노력 경로 일 것입니다.

기다리다! 여기서 매크로는 이미 존재하며 질문은 연결에 관한 것입니다.

생각하면할수록 접미사가 더 좋아 보인다. 예를 들면 :

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)`

모든 수준의 중첩을 허용하고 읽기 가능합니다. ? 및 향후 가능한 연산자와 원활하게 작동합니다. 신규 이민자에게는 약간 낯설어 보이지만 문법 이익이 그것을 능가 할 수 있습니다.

주된 이유는 await 가 함수 호출이 아닌 별도의 키워드 여야하기 때문입니다. 너무 중요하므로 텍스트에 자체 하이라이트와 위치가 있어야합니다.

@Pzixel , @HeroicKatora , @skade

예를 들어 Python yield 및 yield from 표현식을 참조하십시오. 외부 함수는 생성기가 다시 시작될 때 yield 의 결과가 될 값을 제공 할 수 있습니다. 이것이 @valff가 의미하는 따라서 yield 에는 ! 또는 () 이외의 유형도 있습니다.

코 루틴의 시점에서 yield 및 await 일시 중단하고 (결국) 값을 반환 할 수 있습니다. 따라서 그들은 단지 같은 동전의 양면에 불과합니다.

그리고 또 다른 구문 가능성 인 _square-brackets-with-keyword_를 버리고 부분적으로 이것을 강조합니다 (구문 강조를 위해 yield 사용) :

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

"접미사 키워드"가 가장 의미가 있습니다. future-expression과 await 구분하는 공백 이외의 문자가있는 접미어도 나에게 의미가 있지만 '.' 그것은 메서드에 대한 것이고 await 는 메서드가 아닙니다. 그러나 await 를 접두사 키워드로 사용하려면 여러 가지를 함께 연결하려는 사람들을 위해 await self 를 호출하는 Trait 또는 메서드의 @XX 제안을 좋아합니다 (아마도 await 메소드의 이름을 지정할 수 없습니다. wait 할 수 있습니다. 개인적으로 나는 긴 체인이 읽기 어렵 기 때문에 접두사 또는 접미사가 나를 위해 작동하기 때문에 줄마다 대기하고 체인이 아닌 것을 만들 것입니다.

나는 wait 이미 존재하고 미래를 막는다는 것을 잊었다. 그래서 그 생각을 긁어 라.

@roland 나는 구체적으로 이것을 언급하고 있는데, 이것은 타입 비문에 대해 논의합니다 : https://github.com/rust-lang/rust/issues/57640#issuecomment -456023146

@rolandsteiner 그래서 당신은 작성

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

내가 다음과 같이 쓸 때 :

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

@skade 오, 당신은 내가 생각했던 것과 다른 의견을 의미했습니다. : stuck_out_tongue :

@Pzixel 결국 Generator::resume 가 값을 가질 가능성이 있으므로 yield expr 은 비 () 유형을 갖게됩니다.

따라서 yield 에는 ! 또는 () 이외의 유형도 있습니다.

@valff , @rolandsteiner yield 이 재개 값을 반환 할 가능성이 낮다는 것을 알았 습니다.이 값은 생성기 구문 및 / 또는 특성을 사용하기 어렵게 만들지 않고 정적으로 형식화 된 언어에 맞추기가 어렵습니다. 재개 인수가있는 원래 프로토 타입은이 인수를 참조하기 위해 키워드 gen arg 를 사용했습니다. 이와 유사한 것은 IMO에서 잘 작동 할 가능성이 훨씬 더 높습니다. 이 관점에서 yield 는 여전히 () 반환하므로 await 대한 논의에 많은 영향을주지 않아야합니다.

내 생각 await 있기 때문에 중, 접두사 연산자해야 async (그리고 내가 기대 yield 접두사가 될뿐만 아니라 위해). 또는 접미사 위치에서 사용되는 일반적인 방법으로 사용하십시오.

그러나 여기에서 모든 자전거 흘림이 실행되지는 않습니다. Rust의 다른 어떤 것도 가지고 있지 않은 postfix 키워드를 고려하는 이유는 무엇입니까? 그것은 언어를 너무 이상하게 만들 것입니다.

또한 미래를 연결하면 왜 흥미로울 수 있는지 알 수 있습니다. 그러나 체이닝이 기다리고 있습니까? 그게 무슨 뜻이야? 새로운 미래를 돌려주는 미래? Rust가 일류 시민으로서 그 관용구를 갖기를 바라는 것이 정말 일반적인 관용구입니까? 우리가 그것에 대해 정말로 관심이 있다면 다음과 같이해야한다고 생각합니다.

1. 메서드 (예 : foo.await() )로 이동합니다. 이상한 접미사 키워드를 소개하지 않으며 우리 모두 그 의미를 알고 있습니다. 우리는 그것과 연결할 수도 있습니다.
2. 정말로 키워드 / loloperator를 원한다면 나중에 그 질문을 해결할 수 있습니다.

또한 개인적인 의견을 제공하기 위해 접미사 키워드 위치에서 await 를 싫어 합니다.

접두사 await 는 다른 언어에서 사용되는 이유-자연어와 일치합니다. 당신은 "나는 당신의 도착을 기다릴 것입니다"라고 말하지 않습니다. JavaScript를 작성했지만 약간 편견이있을 수 있습니다.

나는 또한 await 체인이 과대 평가되었다고 생각한다고 말할 것입니다. 향후 결합 자에 비해 async/await 의 가치는 if , match 등과 같은 표준 언어 구조를 활용하여 비동기 코드를 순차적으로 작성할 수 있다는 것입니다. 어쨌든 당신은 당신의 기다림을 깨고 싶을 것입니다.

async/await 대해 너무 많은 마법 구문을 구성하지 마십시오. 언어의 일부일뿐입니다. 제안 된 메소드 구문 (예 : foo.await() )은 IMO가 일반 메소드 호출에 너무 직교하고 너무 마술 적입니다. proc-macro 기계가 제자리에 있습니다. 그 뒤에 숨겨 보는 건 어떨까요?

함수 방어에서 async 대신 await 키워드를 사용하는 것은 어떻습니까? 예를 들면 :

await fn foo(future: impl Future<Output = i32>) -> i32 {
    future
}

이 await fn 는 async 컨텍스트에서만 호출 할 수 있습니다.

async {
    let n = foo(bar());
}

그리고 let n = (await foo(bar())); 탈당합니다.
그런 다음 await 키워드 외에도 Future await 트레이 트는 후위 위치에서 await 로직을 사용하기위한 await 메소드를 구현할 수 있습니다. 예를 들면 다음과 같습니다.

async {
    let n = bar().awaited();
}

또한 누군가가 발전기와의 관계를 설명해 줄 수 있습니까? async / await 이 (가) 생성기가 안정화되기 전에 구현된다는 사실에 놀랐습니다.

@phaazon 생성기가 async / await 대한 내부 구현 세부 사항으로 Rust에 추가되었습니다. 이를 안정화하기위한 현재 계획은 없으며 비 실험적 RFC가 필요합니다. (개인적으로 나는 그것들이 안정되기를 원하지만 적어도 1 ~ 2 년 정도 남았을 것 같습니다. 아마도 async / await 가 안정되고 그것에 대한 약간의 경험).

@XX 함수 정의에서 await 를 사용하면 async 의 의미를 깨뜨리는 것 같습니다 . 표준을 고수합시다, 그렇지 않습니까?

@phaazon 이것이 async 의미론을 어떻게 깨뜨리는 지 더 자세히 지정할 수 있습니까?

대부분의 언어는 async 를 사용하여 비동기가 될 무언가를 소개하고 await 기다립니다. 가지고 그래서 await 대신 async 나에게 좀 이상한 것입니다.

@phaazon 아니요, 대신 아닙니다. 전체 예 :

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())`

유효한 경우 체인에서 사용하기 위해 await-method를 구현할 수 있습니다.

async {
    let n = first().awaited()?.second().awaited()?;
    // let n = (await (await first())?.second())?;
}

제 생각에는 접미사가 너무 마법적이고 언어에 익숙하지 않은 "느낌"을 기다리는 것은 중요하지 않습니다. .await() 또는 .await!() 메서드 구문을 채택하면 Future 에는 .await() 또는 .await!() 메서드가 있음을 설명하는 것이 문제입니다. 이치에 맞는 경우를 기다릴 때도 사용할 수 있습니다. 이전에 본 적이 없더라도 5 분 동안 생각하는 것이 이해하기 어렵지 않습니다.

게다가 접두사 키워드를 사용하면 다음과 같은 상자를 작성하지 못하게하는 이유는 무엇입니까 (지금 세부 사항을 처리 할 인프라가 없기 때문에 불완전한 의사 코드).

trait AwaitChainable {
    fn await(self) -> impl Future;
}

impl<T: Future> AwaitChainable for T {
    fn await(self) -> impl Future {
        await self
    }
}

그렇게하면 원하는 경우 접미사를 기다릴 수 있습니다. 내 말은, 그것이 어떻게 든 가능하지 않고 컴파일러에 의해 마술처럼 postfix await를 구현해야하더라도 위의 예제와 같은 것을 사용하여 대부분의 작동 방식을 설명 할 수 있습니다. 배우는 것은 어렵지 않을 것입니다.

@ivandardi 저도 같은 생각을했습니다. 하지만이 정의

fn await(self) -> impl Future {
    await self
}

함수가 async -context에서만 호출 될 수 있다고 말하지 않습니다.

@XX 그래, 내가 말했듯이 깨진 의사 코드를 무시하십시오 : PI는 현재 올바른 구문과 특성이 어떻게 작성되어야 하는지를 찾을 수있는 인프라가 없습니다. 컨텍스트.

@XX , @ivandardi 정의에 따라 await 는 async 컨텍스트에서만 작동합니다. 따라서 이것은 불법입니다.

fn await(self) -> impl Future {
    await self
}

반드시

async fn await(self) -> impl Future {
    await self
}

다음과 같은 async 컨텍스트에서만 호출 할 수 있습니다.

await future.await()

모든 목적을 무너 뜨리는 것이죠.

이 작업을 수행하는 유일한 방법은 async 완전히 변경하는 것입니다.

@ivandardi 내 버전의이 진화 :

fn await(self) -> T { // How to indicate using in async-context only?
    await self
}

```녹
await fn await (self)-> T {// 비동기가 이미 사용 되었기 때문에
자신을 기다리다
}

```rust
await fn await(self) -> T {
    self // remove excess await
}

@CryZe @XX 왜 나에게 야유하는거야? 난 괜찮아.

당신이 뭘 하려는지 @XX (예 만들 비동기의 의미를 변경하고 완전히 기다리고하는 것입니다 await 에서 어떻게 든 다른 컨텍스트 async 문맥을). 언어 개발자들로부터 많은 지원을받지 못할 것 같아요

@EyeOfPython 이 정의는 예상대로 작동하지 않습니다.

async fn await(self) -> impl Future {
    await self
}

더 가능성 :

#[call_only_in_async_context_with_derived_await_prefix]
fn await(self) -> impl Future {
    self
}

이것이 가상의 의사 구문이라는 것을 무시했기 때문에 나는 반대 투표입니다. 본질적으로 그들의 요점은 Rust가 언어가 이해하는 Drop 및 Copy와 같은 특수 특성을 추가 할 수 있다는 것입니다. 그러면 await 키워드처럼 유형과 상호 작용하는 유형에 .await ()를 호출 할 수있는 기능이 추가됩니다. 또한 투표는 어쨌거나 RFC와 관련이없는 것으로 간주됩니다. 요점은 업 보트 / 다운 보트에 의해 시각화되는 것과 같은 주관적인 감정에 기반한 것이 아니라 객관적인 솔루션을 찾는 것입니다.

이 코드가 무엇을해야하는지 이해할 수 없습니다. 그러나 현재 비동기 대기가 작동하는 방식과는 관련이 없습니다. 관심이 있으시면이 스레드에서 제외하고 전용 RFC를 작성하십시오.

@CryZe 해당 유형을 사용할 수 있습니다. 미래라고합니다. 그리고 오래 전에 async / await가 비동기 코드 변환만을 목표로하는 메커니즘이라는 것에 동의했습니다. 일반적인 바인드 표기법이 아닙니다.

@ivandari 귀하의 postfix await는

@ Matthias247 그들이 제안하려는 것은 postfix가 메서드 호출 구문을 갖도록 기다리는 방법이었습니다. 이렇게하면 Rust는 #, @ 또는 ...와 같은 임의의 새 기호를 도입 할 필요가 없습니다.? 연산자이며 여전히 상당히 자연스럽게 보입니다.

let result = some_operation().await()?.some_method().await()?;

따라서 아이디어는 컴파일러가 일반 await 키워드 (이 경우에는 전혀 필요하지 않음)와 동일한 방식으로보고 비동기를 변환하는 Future 특성에 대한 특별한 종류의 메서드를 기다리는 것입니다. 거기에서 생성기로 코드를 작성하십시오. 그런 다음 await some_future()? 로 왼쪽 오른쪽 대신 왼쪽에서 오른쪽으로 적절한 논리적 제어 흐름을 갖게되며 이상한 새 기호를 도입 할 필요가 없습니다.

(그래서 tl; dr : 메서드 호출처럼 보이지만 실제로는 접미사 대기입니다)

접미사 구문을 고려하여 명시 적으로 언급하지 않은 것은 오류 및 옵션 결합 자의 유병률입니다. 이것은 자동 역 추적 대신 .map_err()? 있습니다.

특히 다음과 같은 것들 :

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))?;

가독성이 떨어집니다 (어떤 접미사 구문이 고려되는지는 신경 쓰지 않습니다) :

let parsed = reqwest::get(..)
    .send() await
    .map_err(add_context)?
    .json() await
    .map_err(add_context)?;

_하지만 _이 기본 서식에는 다중 변수 접근 방식보다 많은 행이 있습니다. 다중 대기가없는 표현식은 postfix-await를 사용하여 수직 공간을 덜 차지해야하는 것처럼 보입니다.

지금은 비동기 코드를 작성하지 않기 때문에 무지에서 말하고 있습니다. 쌓아 두 어서 미안합니다. 실제로 이것이 문제가되지 않는다면 훌륭합니다. 나는 오류 처리를 다르게 수행하는 다른 언어와 더 유사하기 위해 적절한 오류 처리가 덜 인체 공학적으로 만들어지기를 원하지 않습니다.

네, 그게 제가 의미하는 바입니다. 상황에 따라 접두사를 사용할 것인지 접두사를 사용할 것인지 선택할 수있는 두 세계의 장점이 될 것입니다.

@XX 사용자 코드로 표현할 수없는 경우 해당 기능을 구현하기 위해 컴파일러에 의존해야합니다. 그러나 접미사가 어떻게 작동하는지 이해하는 측면에서는 피상적 인 이해 일지라도 이전에 게시 한 설명은 여전히 ​​작동합니다.

@CryZe , @XX ,

처음에는 부드럽지만 Rust 철학과는 전혀 일치하지 않습니다. 심지어 sort 반복자에 방법은 없습니다 반환 할 self 및 휴식 메서드 호출 체인 할당을 명시 적으로 확인합니다. 그러나 당신은 일반적인 함수 호출과 구별 할 수없는 완전히 암시적인 방식으로 구현되기를 기대합니다. IMO는 기회가 없습니다.

네, 그게 제가 의미하는 바입니다. 상황에 따라 접두사를 사용할 것인지 접두사를 사용할 것인지 선택할 수있는 두 세계의 장점이 될 것입니다.

왜 그것이 목표 여야합니까? Rust는 다른 모든 제어 흐름 (예 : break , continue , if 등)에 대해이를 지원하지 않습니다. 특정 의견으로는 더 멋지게 보입니다.

일반적으로 await 는 매우 특별하며 일반적인 메서드 호출이 아니라는 점을 모두에게 상기시키고 싶습니다.

• 디버거는 스택이 풀리고 다시 설정 될 수 있기 때문에 스테핑이 대기 할 때 이상하게 동작 할 수 있습니다. 내가 기억하는 한 C # 및 Javascript에서 비동기 디버깅을 작동하는 데 많은 시간이 걸렸습니다. 그리고 그들은 디버거에서 일하는 유료 팀을 가지고 있습니다!
• 대기 지점을 통과하지 못하는 로컬 개체는 실제 OS 스택에 저장할 수 있습니다. 그렇지 않은 것들은 생성 된 미래로 옮겨 져야하는데, 결국 필요한 힙 메모리 (미래가 사는 곳)에 차이를 만들 것입니다.
• await 포인트를 통한 차입은 생성 된 선물이 !Unpin 이어야하는 이유이며, 기존 결합 자 및 메커니즘 중 일부에 많은 불편을 초래합니다. 미래에 빌리지 않는 async 메소드에서 Unpin 선물을 생성하는 것이 잠재적으로 가능할 수 있습니다. 그러나 await 가 보이지 않으면 결코 발생하지 않습니다.
• async / await의 현재 상태에서 다루지 않는 다른 예상치 못한 차용 검사기 문제가있을 수 있습니다.

트윗 담아 가기

C #에 대해 제공하는 예제는 전적으로 필수적이며 Rust에서 자주 볼 수있는 기능적 스타일의 긴 체인과 같은 것은 없습니다. 이 LINQ 구문은 DSL 일 뿐이며, 제가 조금만 살펴본 foo().bar().x().wih_boo(x).camboom().space_flight(); 와는 다릅니다. C # 코드 예제는 대부분의 인기있는 프로그래밍 언어와 마찬가지로 100 % 필수입니다. 그것이 우리가 langue X가했던 것을 받아 들일 수없는 이유입니다. 왜냐하면 그것은 똑같지 않기 때문입니다.

IMO 접두사 표기법은 명령형 코딩 스타일에 완벽하게 맞습니다. 그러나 Rust는 두 가지 스타일을 모두 지원합니다.

스케이드

나는 기능적 스타일의 문제에 대한 당신의 의견에 동의하지 않습니다. 간결하게 유지하기 위해-둘 중 하나를 선호하는 사람들이 있다는 데 동의합시다.

@ Matthias247 아니요, 얼마나 멋진 지 다른 특별한 이유가 있습니다. Rust가 연결을 권장하기 때문입니다. 그리고 "오, 다른 제어 흐름 메커니즘에는 접미사 구문이 없는데 왜 await가 특별해야합니까?"라고 말할 수 있습니다. 음, 그건 잘못된 평가입니다. 접미사 제어 흐름이 있습니다. 그들은 우리가 호출하는 메소드의 내부에 있습니다. Option::unwrap_or 는 postfix match 문을 수행하는 것과 같습니다. Iterator::filter 는 접미사 if 문을 수행하는 것과 같습니다. 제어 흐름이 연결 구문 자체의 일부가 아니라고해서 이미 접미사 제어 흐름이 없다는 의미는 아닙니다. 그런 관점에서, await 접미사를 추가하는 것은 실제로 우리가 가진 것과 일치 할 것입니다. 이 경우 Iterator 작동 방식과 더 유사한 것을 가질 수 있으며 원시 접미사를 기다리는 대신 Future::await_or 와 같은 await 결합자를 가질 수 있습니다. 어느 쪽이든 접미사를 기다리는 것은 외모의 문제가 아니라 기능과 삶의 질의 문제입니다. 그렇지 않으면 우리는 여전히 try!() 매크로를 사용하고있을 것입니다. 그렇죠?

@dpc

C #에 대해 제공하는 예제는 전적으로 필수적이며 Rust에서 자주 볼 수있는 기능적 스타일의 긴 체인과 같은 것은 없습니다. LINQ 구문은 DSL 일 뿐이며 foo (). bar (). x (). wih_boo (x) .camboom (). space_flight (); 저는 약간의 구글 검색을 해봤고, C # 코드 예제는 대부분의 인기있는 프로그래밍 언어와 마찬가지로 100 % 필수로 보입니다. 그것이 우리가 langue X가했던 것을 받아 들일 수없는 이유입니다. 왜냐하면 그것은 똑같지 않기 때문입니다.

그것은 사실이 아니지만 (예를 들어 polly 와 같은 어떤 프레임 워크도 확인할 수 있습니다), 그것에 대해 논쟁하지 않겠습니다. 나는 두 언어 모두에서 많은 체인 코드를 봅니다. 그러나 실제로는 모든 것을 다른 만드는 일이있다. 그리고 그것은 Try 특성이라고합니다. C #은 이와 유사한 것이 없으므로 await 포인트를 초과하는 작업을 수행하지 않는다고 가정합니다. 예외가 발생하면 호출자를 위해 자동으로 래핑되고 발생합니다.

? 연산자를 수동으로 사용해야하는 Rust의 경우는 아닙니다.

await 포인트를 넘어서야하는 경우 "결합 된"연산자 await? , 확장 언어 규칙 등을 생성하거나 await 접미사를 만들 수 있습니다. 약간 외계인 구문이지만 누가 신경 쓰나요?).

그래서 나는 현재 postfix가 더 실용적인 해결책으로 기다리고 있다고 봅니다. 내가 가지고있는 유일한 제안은 await() 또는 await!() 아닌 공백으로 구분 된 전용 키워드 여야합니다.

정상적인 .await () 메서드를 정당화하는 좋은 이유가 있다고 생각합니다. 생각해 보면 다른 차단 방법과 다르지 않습니다. .await () 메서드를 호출하면 (녹색 일 수 있음) 스레드의 실행이 중지되고 실행중인 런타임이 어느 시점에서 스레드 실행을 다시 시작합니다. 따라서 Mutex 또는 std 채널이 있는지 여부에 관계없이 모든 의도와 목적을 위해 다음과 같습니다.

let result = my_channel().recv()?.iter().map(...).collect();

또는 다음과 같은 미래 :

let result = my_future().await()?.iter().map(...).collect();

다르지 않습니다. 둘 다 각각의 recv () / await ()에서 실행을 차단하고 둘 다 동일한 방식으로 연결합니다. 유일한 차이점은 await ()가 OS의 무거운 스레딩이 아닌 다른 실행기에서 실행될 수 있다는 것입니다 (그러나 단일 스레드 실행기의 경우에는 매우 적합 할 수 있음). 따라서 많은 양의 연결을 막는 것은 똑같은 방식으로 영향을 미치며 실제 보푸라기가 발생할 수 있습니다.

그러나 여기서 내 요점은이 코드를 작성하는 사람의 관점에서 .recv () 또는 .await ()에 큰 차이가 없다는 것입니다. 둘 다 실행을 차단하고 결과를 사용할 수 있으면 반환하는 메서드입니다. . 따라서 모든 의도와 목적을 위해 거의 일반적인 방법이 될 수 있으며 완전한 키워드가 필요하지 않습니다. Mutex 및 std 채널에 대한 recv 또는 lock 키워드도 없습니다.

그러나 rustc은 분명히 전체 코드를 생성기로 바꾸고 싶어합니다. 그러나 그것은 실제로 언어 관점에서 의미 상 필요합니까? 실제 OS 스레드를 차단하여 await를 구현하는 rustc에 대한 대체 컴파일러를 작성할 수 있다고 확신합니다 (비동기 fn을 입력하면 스레드를 생성 한 다음 awaiting이 해당 스레드를 차단합니다). 이는 매우 순진하고 느린 구현이지만 의미 상 똑같은 방식으로 작동합니다. 따라서 실제 rustc가 생성기로 대기한다는 사실은 의미 상 필요하지 않습니다. 그래서 저는 실제로 rustc가 .await () 메서드에 대한 호출을 생성기로 바꾸는 것이 rustc의 최적화 구현 세부 사항으로 볼 수 있다고 주장합니다. 그렇게하면 .await ()가 완전한 방법이고 완전한 키워드가 아니라는 것을 정당화 할 수 있지만, 여전히 rustc가 모든 것을 제너레이터로 바꾸도록 할 수 있습니다.

@CryZe .recv() 와 달리 프로그램의 다른 위치에서 await 를 안전하게 중단 할 수 있으며 await 옆에있는 코드는 실행되지 않습니다. 그것은 큰 차이이며 우리가 await 묵시적으로하지 말아야하는 가장 가치있는 이유입니다.

@ I60R 키워드로 기다리는 것보다 덜 명시 적이 지 않습니다. 원한다면 IDE에서 동일한 방식으로 강조 표시 할 수 있습니다. 키워드를 접미사 위치로 이동하기 만하면 실제로 놓치기가 덜하다고 주장합니다 (정확히 실행이 중지되는 위치에 있음).

미친 아이디어 : 암시 적 대기 . 이 스레드는 이미 접미사 대 접두사 토론으로 너무 바빠서 별도의 스레드로 이동했습니다.

@CryZe

정상적인 .await () 메서드를 정당화하는 좋은 이유가 있다고 생각합니다. 생각해 보면 다른 차단 방법과 다르지 않습니다.

https://github.com/rust-lang/rust/issues/57640#issuecomment -456147515를 다시 읽으십시오.

@ Matthias247 이것들은 아주 좋은 점입니다.

await를 함수, 멤버 또는 암시 적으로 만드는 것에 대한이 모든 이야기는 근본적으로 유효하지 않습니다. 그것은 행동이 아니라 변화입니다.

높은 수준에서 컴파일러는 키워드 또는 매크로를 통해 await 표현식을 특수 생성기 yield 표현식으로 변환하고, 그 자리에서 차용 및 기타 작업을 설명합니다.

이것은 명시 적 이어야 합니다.

가능한 한 키워드처럼 보이거나 분명히 매크로로 코드를 생성해야합니다.

마법의 방법, 특성, 회원 등은 특히 신규 사용자에게 너무나 쉽게 오해하거나 오해하기 쉽습니다.

접두어 키워드 await 또는 접두어 매크로 await는이를 수행하는 가장 적합한 방법 인 것처럼 보이며, 이는 다른 많은 언어가 그렇게하는 것처럼 의미가 있습니다. 우리는 그것을 좋게 만들기 위해 특별 할 필요가 없습니다.

헉헉

마법의 방법, 특성, 회원 등은 특히 신규 사용자에게 너무나 쉽게 오해하거나 오해하기 쉽습니다.

확장 할 수 있습니까? 가능한 경우 .await!() 변형에 대해 더 구체적으로 설명합니다.

내 생각에 foo.await!() 를 갖는 것은 특히 적절한 구문 강조 표시를 사용하여 읽기 어렵지 않습니다. 무시해서는 안됩니다.

그것의 의미를 오해? 기본적으로하는 것은 다음과 같습니다 (mystakes 유형 무시).

trait Future {
    fn await!(self) -> Self::Item {
        await self
    }
}

AKA await this_foo 및 this_foo.await!() 는 정확히 동일합니다. 그것에 대해 오해하기 쉬운 것은 무엇입니까?

그리고 새로운 사용자의 주제에 대해 : 새로운 사용자는 무엇입니까? 일반적인 프로그래밍 또는 프로그래밍 언어 배경이있는 Rust를 처음 사용하는 언어입니까? 전자의 경우 비동기 프로그래밍을 바로 사용할 수 있을지 의심 스럽기 때문입니다. 후자의 경우, 혼란없이 postfix await (위에서 설명한대로)의 의미를 설명하는 것이 더 쉽습니다.

또는 접두사 await 만 추가되면 내가 아는 어떤 것도 Rust 코드 형식의 입력으로 사용되는 프로그램 생성을 중지합니다

foo.bar().baz().quux().await!().melo().await!()

그리고 그것을

await (await foo.bar().baz().quux()).melo()

뿡 빵뀨

.await!() 는 경우에 따라 좋으며 다음과 같이 await!(...) 와 함께 사용할 수 있습니다.

macro_rules! await {
    // prefix
    ($fut:expr) => {...}

    // postfix
    ($self:Self) => { await!($self) }
}

그러나 postfix 메서드 매크로는 현재 존재하지 않으며 존재하지 않을 수도 있습니다.

이것이 미래에 가능성이 있다고 생각한다면 지금은 await!(...) 매크로를 사용하고 구현 될 때 나중에 접미사를 추가해야합니다.

두 매크로를 모두 갖는 것이 이상적이지만 앞으로 접미사 매크로를 구현할 의도가 없다면 접두사 키워드 await 가 가장 좋은 방법 일 것입니다.

@novacrazy 나는 그것에 동의 할 수 있고 그것은 나의 원래 제안이다. 우리는 지금 await!() 를 추가하고 우리가 갈 때 접미사 양식을 찾아야합니다. 잠재적으로 접미사 매크로의 가능성에 대해서도 논의하고 언어에서 접미사 매크로를 완벽하게 지원하기 전에 .await!() 접미사를 언어에 임시로 추가 할 수 있는지 논의하십시오. ? 및 Try 특성에서 일어난 일과 비슷합니다. 먼저 특수 사례로 추가되고 나중에 더 일반적인 사례로 확장됩니다. 결정할 때주의해야 할 유일한 것은 일반적인 접미사 매크로 구문이 어떻게 생겼는지이며, 별도의 논의가 필요합니다.

접두어 키워드 await 또는 접두어 매크로 await는이를 수행하는 가장 적합한 방법 인 것처럼 보이며, 이는 다른 많은 언어가 그렇게하는 것처럼 의미가 있습니다.

분명히 _workable_이지만 두 가지 주장 만 기억하고 있으며 설득력이 없다고 생각합니다.

• 그것이 다른 언어가하는 방법입니다.
  
  
  
  • 멋지지만, 우리는 이미 처음부터 시작하는 await 대신 not-running-unless- poll ed 같은 일을하고 있습니다. 왜냐하면 rust는 근본적으로 다르기 때문입니다. 언어
  
  
• 사람들은 줄 시작 부분에 await 를 보는 것을 좋아합니다.
  
  
  
  • 하지만 항상있는 것은 아니기 때문에 그것이 유일한 곳이라면 문제가있을 것입니다.
  
  
  • 그것은보고 그냥 쉽게로의 await 입력 S foo(aFuture.await, bFuture.await) 가있는 것처럼 접두사
  
  
  • Rust에서 제어 흐름을 살펴보면 이미 ? 라인의 _end_를 스캔하고 있습니다.
  
  

내가 뭐 놓친 거 없니?

논쟁이 "아, 그것들은 거의 같다"였다면, 나는 "글쎄, 우리가 정말로 신경 쓰지 않는다면 다른 사람들이하는 일을하는 것만 큼 좋을지도 모른다"에 절대적으로 동의 할 것입니다. 그러나 나는 그것이 우리가있는 곳이라고 생각하지 않습니다.

@scottmcm 예, "아, 그들은 거의 동일합니다." 적어도 사용자의 관점에서.

따라서 우리는 가독성, 친숙 함, 유지 관리 및 성능의 적절한 균형을 찾아야합니다. 따라서 마지막 주석의 진술은 await!() 매크로를 사용하여 나중에 후위 메서드 매크로 ( .await!() )를 추가하거나 지루한 접두사 키워드 await 를 추가하려는 경우 참입니다

지루함이 좋기 때문에 지루하다고 말합니다. 우리는 이것들을 사용하여 코드를 작성할 때 구문 자체에서 벗어나기를 원합니다.

f.await() 가 좋은 생각이 아니라면 접두사 구문을 선호합니다.

1. 사용자로서 저는 제가 사용하는 언어에 문법 규칙이 몇 개 밖에 없기를 바라며,이 규칙을 사용하여 어떤 일을하는지 확실하게 추론 할 수 있습니다. 여기 저기 예외가 아닙니다 . Rust에서 async 는 처음에 있고, await 는 예외가 아닙니다. 그러나 f await , 게시물 키워드 형식은됩니다. f.await 는 예외 인 필드 액세스처럼 보입니다. f.await!() 에는 접미사 매크로가 언어로 표시되지 않았으며 다른 경우에 좋은 예외 가 무엇인지 모릅니다. 이러한 구문이 일회성 예외가 아닌 규칙 이되는 방법에 대한 답변이 없습니다.

2. 예외가 발생하면 직관적으로 이해하기를 바랍니다. ? 를 예로 들어 보면 다른 언어에서는 자주 사용되지 않기 때문에 예외로 보일 수 있습니다. f()?.map() 는 compute f ()와 거의 비슷하며이 결과가 좋은가요? 여기에서 ? 는 그 자체를 설명합니다. 하지만 f await 왜 접미사입니까?, f.await 경우 await 필드, f.await!() 왜 매크로가 해당 위치에 나타나는지 묻습니다. 적어도 언뜻보기에는 설득력 있고 직관적 인 감각을 제공하지 않습니다.

3. 첫 번째 요점을 확장하면 Rust는 시스템 언어가되기를 가장 원합니다. 여기서 주요 플레이어 인 C / C ++ / Go / Java는 모두 다소 필수입니다. 저는 또한 대부분의 사람들이 명령형 언어, C / Python / Java, Haskell 등으로 경력을 시작한다고 믿습니다. 시스템 개발자와 차세대 개발자가 Rust를 채택하도록 설득 할 것 같습니다. Rust는 먼저 명령형 스타일에서 잘하고 그다음에는 기능적이어야합니다. 매우 기능적이지만 익숙한 명령 적 느낌이 없습니다.

4. 체인을 분할하여 여러 줄로 작성하는 것은 잘못이 없다고 생각합니다. 장황하지 않을 것입니다. 그것은 단지 명시 적 입니다.

토론이 한 방향에서 다른 방향 (접두사 대 접미사)으로 지속적으로 이동하는 방식을 볼 때 await 키워드에 문제가 있다는 강한 의견이 생겨 완전히 후퇴해야합니다. 대신 현재 스레드에 게시 된 모든 의견 중에서 매우 좋은 타협이 될 것이라고 생각하는 다음 구문을 제안합니다.

// 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();

첫 번째 단계에서는 특정 상부 구조를 처리하는 오류없이 일반 접두사 연산자로 구현합니다.

// 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()?;

두 번째 단계에서는 적절한 오류 처리를 허용하는 지연된 접두사 연산자 구문을 구현합니다.

// now `go` takes precedence over `?` if present
let response = client.get("https://my_api").go send()?;
let body: MyResponse = response.go into_json()?;

그게 다야.

이제 더 많은 컨텍스트를 제공하는 몇 가지 추가 예제를 살펴 보겠습니다.

// 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이 구문은 모든 측면에서 대안보다 낫습니다.

✓ 일관성 : Rust 코드 내부에서 매우 유기적으로 보이며 코드 스타일을 깨지 않아도됩니다.
✓ 구성 가능성 : 체인 및 오류 처리와 같은 다른 Rust 기능과 잘 통합됩니다.
✓ 단순성 : 짧고 설명 적이며 이해하기 쉬우 며 작업하기 쉽습니다.
✓ 재사용 성 : 지연된 접두사 연산자 구문은 다른 컨텍스트에서도 유용합니다.
✓ 문서 : 호출 측 디스패치가 어딘가에 흐르고 반환 될 때까지 기다린다는 것을 의미합니다.
✓ 익숙 함 : 이미 익숙한 패턴을 제공하지만 트레이드 오프가 적습니다.
✓ 가독성 : 평이한 영어로 읽고 단어의 의미를 왜곡하지 않습니다.
✓ 가시성 : 위치로 인해 코드 어딘가에서 위장하기가 매우 어렵습니다.
✓ 접근성 : 매우 쉽게 검색 할 수 있습니다.
✓ 잘 테스트 됨 : golang은 요즘 비슷한 구문으로 인기가 있습니다.
✓ 놀라움 : 구문을 남용 할뿐만 아니라 오해하기도 어렵습니다.
✓ 만족 : 적은 양의 학습 후에 모든 사용자가 결과에 만족할 것입니다.

편집 : @ivandardi 가 아래 주석에서 지적했듯이 몇 가지 사항을 명확히해야합니다.

1. 예,이 구문은 눈으로 파싱하기가 조금 어렵지만 동시에 가독성 문제가없는 구문을 여기에서 발명하는 것은 불가능합니다. go 구문 내게는 접두사와 정확하게 같은 년대에 접두사 위치하기 때문에, 여기에 적은 악을 것으로 보인다 await , 이연 위치는 접미사에 비해 IMO 더 읽기의 await 예 :

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

await 은 (는) 모호해 보이고 기존의 모든 키워드와 다른 연관성을 갖지만 향후 언젠가 await 블록을 구현하기로 결정하면 차단기가 될 수도 있습니다.

2. RFC 생성, "지연된 접두사 연산자"구문의 구현 및 안정화가 필요합니다. 이 구문은 비동기 코드에만 국한되지 않지만 비동기에서 사용하는 것이 주된 동기가 될 것입니다.

3. "지연된 접두사 연산자"구문 키워드는 다음과 같은 이유로 중요합니다.

• 긴 키워드는 가독성에 좋지 않은 변수와 메소드 사이의 공간을 늘립니다.
• 긴 키워드는 접두사 연산자에 대한 이상한 선택입니다.
• long 키워드는 비동기 코드가 동기화 된 것처럼 보이길 원할 때 불필요하게 상세합니다.

어쨌든 await 대신 go 를 사용한 다음 2022 년 버전에서 이름을 바꿀 수 있습니다. 그때까지는 다른 키워드 나 연산자가 발명 될 가능성이 큽니다. 그리고 이름 변경이 전혀 필요하지 않다고 결정할 수도 있습니다. await 도 읽을 수 있습니다.

// 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()?;

반대표를 받으려면 다음을 확인하십시오.

• 내가 새로운 것을 설명하는 최고의 연설자가 아닐 수도 있기 때문에 제대로 이해했다고
• 당신의 의견이 편견이 아니라는 사실, 그 구문의 기원에서 많은 편견이 있습니다.
• 아래에 타당한 이유를 입력 할 것입니다.
• 당신의 이유는 즉각적인 감정에 관한 것이 아닙니다. 제가 여기서 장기적인 기능을 디자인하려고했기 때문에

@ I60R

나는 그것에 대해 몇 가지 불만이 있습니다.

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

눈으로 분석하기가 약간 어렵습니다. 언뜻 보면 우리가 db.go 에서 일치한다고 생각할 것입니다.하지만 더 많은 것이 있고 "oooh, ok, load is a method of db"로 이동합니다. IMO는 구문이 주로 작동하지 않을 것입니다. 왜냐하면 메서드는 그 사이에 공백과 키워드 중단없이 항상 자신이 속한 객체에 가까워 야하기 때문입니다.

두 번째로, 귀하의 제안은 "지연된 접두사 연산자 구문"이 무엇인지 정의하고 가능하면 먼저 언어로 일반화해야합니다. 그렇지 않으면 비동기 코드에만 사용되며 "왜 후위 매크로가 아닌가?"에 대한 논의로 돌아갑니다. 너무.

셋째, 키워드가 전혀 중요하지 않다고 생각합니다. 그러나 await 키워드는 2018 년 버전을 위해 예약되었으므로 go 키워드는 제안되기 전에 더 깊은 crates.io 검색을 수행하지 않았으며이를 거쳐야합니다.

토론이 한 방향에서 다른 방향 (접두사 대 접미사)으로 지속적으로 이동하는 방식을 보면 await 키워드에 문제가 있다는 강한 의견이 생겨 완전히 후퇴해야합니다.

우리는 (반) 암시 적 기다림을 가질 수 있고 모든 것이 괜찮을 것이지만, 비동기 함수의 전체 요점은 구현 세부 사항을 숨기고보기 좋게 만드는 것임에도 불구하고 Rust 커뮤니티에서 힘든 판매가 될 것입니다. io one을 차단하는 것과 같습니다.

@dpc 내가 생각할 수있는 가장 좋은 방법은 unsafe 와 유사한 것입니다.

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

await 블록 안의 모든 것이 자동으로 대기하는 곳. 대신 전체 체인을 기다릴 수 있기 때문에 체인에 대한 postfix await의 필요성을 해결합니다. 그러나 동시에 그 형식이 바람직한 지 확실하지 않습니다. 아마도 다른 누군가가 이것에 대해 정말 좋은 이유를 찾을 수 있습니다.

@dpc 비동기 함수의 요점은 세부 정보를 숨기는 것이 아니라 더 접근하기 쉽고 사용하기 쉽게 만드는 것입니다. 잠재적으로 비용이 많이 드는 작업을 숨기면 안되며 가능한 경우 명시적인 미래를 활용해야합니다.

어느 언어로도 비동기 함수와 동기 함수를 혼동하는 사람은 없습니다. 순전히 상태 머신을 손으로 작성하는 것이 아니라 더 읽기 쉽고 유지 관리가 쉬운 형식으로 작업 시퀀스를 구성하는 것입니다.

또한 @ivandardi 의 예제에서 대기 는 Future 결합자를 사용하는 것을 불가능하게 만들며, 이미 보여 주었 듯이 여전히 매우 강력합니다. 우리는 Future 잡고 기다릴 수 없습니다. 그것은 매우 비효율적입니다.

명확하고, 친숙하고, 읽기 쉽고, 유지 관리가 가능하며, 성능이 뛰어납니다. 접두어 키워드 await 또는 매크로 await!() , 잠재적으로 접미사 매크로 .await!() 가 추가됩니다.

@novacrazy 이상적인 구문을 선택 했더라도 일부 상황에서는 사용자 정의 퓨처 및 결합자를 사용하고 싶습니다. 소프트 사용되지 않을 수 있다는 생각은 Rust의 전체 방향에 의문을 제기합니다.

물론 결합자를 계속 사용할 수 있으며 더 이상 사용되지 않는 것은 없습니다.

? 와 같은 상황입니다. 새 코드는 일반적으로 ? 하지만 (결합 자보다 낫기 때문에) 옵션 / 결과 결합자를 계속 사용할 수 있습니다 or_else 는 여전히 정기적으로 사용됩니다.)

특히 async / await는 map 및 and_then 완전히 대체 할 수 있지만 더 펑키 한 Future 결합자는 여전히 사용할 수 있습니다.

당신이 제공하는 예는 결합 자에 비해 여전히 끔찍해 보입니다.

나는 그렇게 생각하지 않습니다. 그들은 표준 Rust 기능을 사용하기 때문에 훨씬 더 명확하다고 생각합니다.

명확성은 거의 캐릭터 수에 관한 것이지만 정신적 개념과 관련이 있습니다.

await 접미사를 사용하면 더 좋아 보입니다.

some_op().await?
    .another_op().await?
    .final_op().await

원본과 비교할 수 있습니다.

some_op()
    .and_then(|v| v.another_op())
    .and_then(|v2| v2.final_op())

생성기 오버 헤드는 아마도 약간 느리고 더 많은 기계 코드를 생성 할 것입니다.

async / await에서 추가 오버 헤드가 발생할 것이라고 주장하는 이유는 무엇입니까? 생성기와 async / await는 모두 제로 비용과 고도로 최적화되도록 특별히 설계되었습니다.

특히, async / await는 퓨처 컴비 네이터와 마찬가지로 고도로 최적화 된 상태 머신으로 컴파일됩니다.

이러한 생성기 스파게티 상태 머신을 만드는 것보다

퓨처 컴비 네이터 는 또한 후드 아래에 "스파게티 상태 머신"을 생성하는데, 이는 정확히 그들이하도록 설계된 것입니다.

근본적으로 async / await와 다르지 않습니다.

[미래의 결합 자]는 더 효율적인 코드로 컴파일 할 가능성이 있습니다.

잘못된 정보를 퍼 뜨리지 마십시오. 특히 async / await는 Future 결합 자보다 빠를 가능성이 있습니다.

사용자가 접두사 키워드에 만족하지 않는다는 것이 밝혀지면 2019/2020 에디션에서 변경할 수 있습니다.

다른 사람들이 말했듯이, 에디션은 우리가 원할 때마다 만드는 임의의 것이 아니라 몇 년마다 (가장 빠르면) 만 발생하도록 특별히 설계되었습니다.

@Centril이 지적했듯이 나중에 대체하기 위해 잘못된 구문을 만드는 것은 작업을 수행하는 매우 비효율적 인 방법입니다.

토론의 속도는 지금 상당히 높습니다. 그래서 속도를 늦추고 사람들이 따라 잡을 수 있도록하기 위해 일시적으로 문제를 잠갔습니다. 하루 안에 잠금 해제됩니다. 그 때 가능한 한 건설적으로 앞으로 나아가도록 노력하십시오.

하루 후 문제 풀기 ... 이미 언급하지 않은 것을 고려하고 주제에 대한 의견을 유지하십시오 (예 : 암시 적 대기 또는 범위를 벗어난 다른 사항을 고려할 수있는 곳이 아닙니다 ..).

이것은 긴 스레드 였으므로 그 안에 묻혀있는 가장 흥미로운 댓글 중 일부를 강조해 보겠습니다.

@mehcode 는 접두사 및 접미사 위치에 await 된 광범위한 실제 코드를 제공했습니다. https://github.com/rust-lang/rust/issues/57640#issuecomment -455846086

@Centril 은 await!(expr) 를 안정화하는 것이 의도적으로 기술 부채를 추가하는 것이라고 설득력있게 주장했습니다. https://github.com/rust-lang/rust/issues/57640#issuecomment -455806584

@valff 는 expr await 접미어 키워드 구문이 것임을 상기 시켰 습니다 . https://github.com/rust-lang/rust/issues/57640#issuecomment -456023146

@quodlibetor 는 오류 및 옵션 결합 자의 구문 효과가 Rust에 고유하다는 https://github.com/rust-lang/rust/issues/57640#issuecomment -456143523

하루가 끝나면 lang 팀이 여기에서 전화를 걸어야합니다. 합의로 이어질 수있는 공통 기반을 식별하기 위해 postfix 구문의 핵심 문제에 대해 lang 팀 구성원의 명시된 입장을 요약하는 것이 도움이 될 것입니다.

• @Centril 은 후위 구문에 대한 지원을 표명하고이 티켓의 다양한 변형을 탐색했습니다. Centril은 특히 await!(expr) 안정화를 원하지 않습니다 .

• @cramertj 는 postfix 구문 및 특히 expr await postfix 키워드 구문에 대한 지원 을

• @joshtriplett 은 접미사 구문에 표현 했으며 접두사 버전 도 제공해야한다고 제안했습니다.

• @scottmcm 은 후위 구문에 표현했습니다 .

• @withoutboats 는 매크로 구문을 안정화하고 는 expr await 접미어 키워드 구문이 "실제 기회"를 갖는 것으로 간주 합니다.

• @aturon , @eddyb , @nikomatsakis 및 @pnkfelix 는 아직 문제 # 57640 또는 # 50547에서 구문에 대한 입장을 표현하지 않았습니다.

그래서 우리가 예 / 아니오에 대한 답을 알아 내기 위해 필요한 것 :

• 접두사 구문이 있어야합니까?
• 접미사 구문이 있어야합니까?
• 지금 접두사 구문을 가지고 나중에 접두사 구문을 알아 내야합니까?

접두사 구문을 사용하면 사람들이 가장 받아들이는 두 가지 주요 경쟁자가 있습니다. 이 주석 에서 볼 수 있듯이 유용함과 분명함입니다. await!() 에 대한 주장은 상당히 강력해서 배제되었다고 생각합니다. 따라서 Useful 또는 Obvious 구문을 원하는지 알아 내야합니다. 제 생각에는 일반적으로 덜 괄호를 사용하는 구문을 사용해야합니다.

그리고 접미사 구문에 관해서는 더 까다 롭습니다. 공백이있는 접미사 await 키워드에 대한 강력한 인수도 있습니다. 그러나 그것은 코드의 형식에 따라 매우 다릅니다. 코드의 형식이 잘못된 경우 공백이있는 접미사 await 키워드가 정말 나빠 보일 수 있습니다. 따라서 먼저 모든 Rust 코드가 rustfmt로 올바르게 포맷되고 rustfmt가 한 줄에 맞더라도 항상 다른 줄로 묶인 awaits를 분할해야한다고 가정해야합니다. 그렇게 할 수 있다면 그 구문은 매우 괜찮은 것입니다. 가독성 문제와 한 줄 체인 중간에있는 공백과의 혼동 문제를 해결하기 때문입니다.

마지막으로 접두사와 접미사를 모두 사용하는 경우 두 구문의 의미를 파악하고 적어 두 구문이 서로 상호 작용하는 방식과 하나가 다른 구문으로 어떻게 변환되는지 확인해야합니다. postfix 또는 prefix await 중 하나를 선택해도 코드 실행 방법이 변경되어서는 안되므로 가능해야합니다.

내 사고 과정과 표면 구문 제안에 접근하고 평가하는 방법을 명확히하기 위해. await ,
다음은 내가 가진 목표입니다 (중요한 순서없이).

1. await 은 (는) 향후 언어 디자인을 가능하게하는 키워드로 남아 있어야합니다.
2. 구문은 최고 수준이어야합니다.
3. Awaiting은 Rust에서 널리 사용되기 때문에 ? 및 일반적으로 메소드로 잘 구성 할 수 있도록 연결 가능해야합니다. 의미있는 세분화가 아닐 수있는 임시 let 바인딩을 강요해서는 안됩니다.
4. await 포인트에 대해 grep 가 쉬워야합니다.
5. 대기 지점을 한 눈에 볼 수 있어야합니다.
6. 구문의 우선 순위는 직관적이어야합니다.
7. 구문은 IDE 및 근육 메모리와 잘 구성되어야합니다.
8. 구문은 배우기 쉬워야합니다.
9. 구문은 쓰기에 인체 공학적이어야합니다.

내 목표 중 일부를 정의한 (아마도 잊었을 것입니다 ...) 다음은 이에 대한 몇 가지 제안에 대한 요약 및 평가입니다.

1. await 를 키워드로 유지하면 await!(expr) 또는 expr.await!() 여부에 관계없이 매크로 기반 구문을 사용하기가 어렵습니다. 매크로 구문을 사용하려면 await 를 매크로로 하드 코딩하고 이름 확인과 통합되지 않거나 (즉, use core::await as foo; 가 불가능 해짐) await 가 키워드로 완전히 포기됩니다.

2. 나는 매크로가 사용자 공간에서 구문을 발명하기위한 것이므로 매크로에 대해 명백히 일류가 아닌 느낌을 가지고 있다고 생각합니다. 기술적 인 요점은 아니지만 이러한 언어의 중심 구조에서 매크로 구문을 사용하면 광택이없는 인상을줍니다. 틀림없이 .await 및 .await() 구문은 최고의 구문도 아닙니다. 하지만 매크로처럼 2 등급은 아닙니다.

3. 연결을 용이하게 하려는 욕구 로 인해 접두사 구문이 제대로 작동하지 않는 반면 접미사 구문은 자연스럽게 메서드 체인과 특히 ? 됩니다.

4. 접미사, 접두사, 매크로 등 await 키워드를 사용하면 Grepping이 가장 쉽습니다.시길 기반 구문이 사용되는 경우 (예 : # , @ , ~ , grepping이 더 어려워집니다. 차이는 크지 않지만 .await await 및 await 보다 await 가 주석에 단어로 포함될 수 있지만 그럴 가능성은 더 적기 때문에 grep하기가 약간 더 쉽습니다. .await

5. 시길은 한 눈에 찾기가 더 어려울 수 있지만 await 는보기 쉽고 특히 구문이 강조 표시됩니다. .await 또는 기타 접미사 구문은 한 눈에보기가 더 어렵거나 await 접미사가 가독성을 제공하지 않는다고 제안되었습니다. 그러나 제 생각에 @scottmcm 은 결과의 미래가 일반적이며 .await? 가 그 자체로 더 많은 관심을 끌 수 있다는 것을 올바르게 지적 합니다. 또한 Scott은 접두사 await 가 정원 경로 문장으로 이어지고 식 중간에있는 접두사가 접미사보다 더 읽기 어렵다는 점에 주목합니다. ? 연산자의 출현으로, Rust 프로그래머는 이미 제어 흐름을 찾기 위해 줄 끝 을

6. .await 및 .await() 의 우선 순위는 완전히 예측 가능하다는 점에서 주목할 만합니다. 필드 액세스 및 메서드 호출 대응으로 작동합니다. 접미사 매크로는 아마도 메서드 호출과 동일한 우선 순위를 가질 것입니다. 한편, await 접두사는 ? (예 : await (expr?) )와 관련하여 일관성 있고 예측 가능하며 유용하지 않은 우선 순위를 갖거나 우선 순위가 일관성이없고 유용합니다 (예 : (await expr)? ). 시길은 원하는 우선 순위를 부여 할 수 있습니다 (예 : ? 에서 직관 가져 오기).

7. 2012 년에 @nikomatsakis 는 Simon Peyton Jones가 "점의 힘"을 부러워하며 그것이 의미하는 기능이나 분야를 좁힐 수있는 IDE 마법을 제공하는 방법을 부러워한다고 한 번 언급했다고 언급했습니다 (p. 56) . 점의 힘은 많은 인기있는 언어 (예 : Java, C #, C ++, ..)에 존재하기 때문에 "점에 도달"하는 것이 근육 메모리에 스며들게했습니다. 이 습관이 얼마나 강력한 지 설명하기 위해 다음은 Re # er가 포함 된 Visual Studio의 @scottmcm 으로 인한 스크린 샷입니다.
   

   C #에는 await 접미사가 없습니다. 그럼에도 불구하고 이것은 유효한 구문이 아닌 자동 완성 목록에 표시 될 정도로 매우 유용합니다. 그러나 .await 가 표면 구문이 아닐 때 .aw 를 시도하는 것은 저를 포함하여 많은 사람들에게 발생하지 않을 수 있습니다. IDE 경험의 이점을 고려하십시오. await expr 및 expr await 구문은 이러한 이점을 제공하지 않습니다.

8. Sigils는 아마도 친숙하지 않을 것입니다. 접두사 await 는 C #, JS 등에 익숙해지면 이점이 있습니다. 그러나 Rust는 await 와 ? 를 별개의 연산으로 분리하지 않습니다. await expr 에서 expr.await 로 이동하는 것도 스트레칭이 아닙니다. 변화는시길을 사용하는 것만 큼 급진적이지 않습니다. 또한 앞서 언급 한 닷 파워로 인해 expr. 를 입력하고 자동 완성 팝업의 첫 번째 옵션으로 await 가 표시되면 .await 을 학습 할 가능성이 있습니다.

9. 시길은 작성하기 쉬우 며 인체 공학적으로도 좋습니다. 그러나 .await 는 입력하는 데 더 오래 걸리지 let 문으로 분리 할 필요가 없어 인체 공학도 향상됩니다. 접두사 await 또는 더 나쁘지만 await!(..) 은 점력과 연결 능력이 모두 부족합니다. .await , .await() 및 .await!() 비교할 때 첫 번째 제안이 가장 간결합니다.

하나의 구문이 모든 목표를 동시에 달성하는 데 가장 적합하지 않기 때문에 절충안을 만들어야합니다. 나에게 가장 많은 이점과 가장 적은 단점이있는 구문은 .await 입니다. 특히, 그것은 연결될 수 있고, 키워드로 await 를 보존하고, 탐색 가능하고, 점력을 가지고 있으므로 학습 가능하고 인체 공학적이며 명백한 우선 순위를 가지며 마지막으로 읽기 가능합니다 (특히 좋은 서식 및 강조 표시).

@Centril 몇 가지 질문을 정리합니다. 먼저 접미사 만 기다리시 길 바라는 것을 확인하고 싶습니다. 둘째, .await 이 필드 액세스라는 이중성에 어떻게 접근할까요? .await 그대로 사용해도됩니까? 아니면 괄호가있는 .await() 사용하여 어떤 종류의 작업이 발생하고 있음을 암시해야합니까? 그리고 셋째, .await 구문을 사용하면 키워드가 아니면 "필드 액세스"식별자일까요?

먼저 접미사 만 기다리시 길 바라는 것을 확인하고 싶습니다.

네. 적어도 지금은.

둘째, .await 이 필드 액세스라는 이중성에 어떻게 접근할까요?

약간의 단점이 있습니다. 점의 힘에는 큰 장점이 있습니다. 구분은 특히 키워드가 강조되고 구문이 자주 사용되므로 사용자가 빠르게 배울 것이라고 생각합니다. 또한 Scott이 언급했듯이 .await? 가 가장 일반적이어서 상황을 더욱 완화 할 수 있습니다. 또한위한 새로운 키워드 항목을 쉽게 추가 할 수 있어야 await 우리는 말에 대해 수행 한 많은처럼 rustdoc에서 fn .

.await 그대로 두는 것이 좋을까요, 아니면 괄호가있는 .await() 사용하여 어떤 종류의 작업이 일어나고 있음을 암시해야합니까?

나는 꼬리가없는 .await 을 선호한다 () ; 끝에 () 가 있으면 대부분의 경우 불필요한 소금처럼 보이며 사용자가이 방법을 더 많이 찾는 경향이 있다고 생각합니다.

그리고 세 번째로 .await 구문을 사용하면 키워드가 아니면 "필드 액세스"식별자일까요?

await 는 키워드로 유지됩니다. 가 발생할 때 아마도 당신이하지 오류로 같은 방법으로 libsyntax을 변경할 것 await 후 . 다음과 AST 다르게 중 하나를 대표하거나 HIR에 내릴 때 ...하지만 대부분 구현 세부입니다 .

모든 문제를 해결해 주셔서 감사합니다! 👍

이 시점에서 핵심 문제는 접미사 구문을 추구할지 여부입니다. 그것이 방향이라면 확실히 우리는 어느 방향으로 좁힐 수 있습니다. 방을 읽으면 접두사 구문을지지하는 대부분의 사람들은 접두사 구문보다 합리적인 접미사 구문을 받아 들일 것입니다.

이 스레드로 들어 오면 접미사 구문이 약한 것처럼 보였습니다. 그러나 4 명의 lang 팀원의 명확한 지원과 5 분의 1 (다른 4 명은 지금까지 침묵)의 개방성을 끌어 냈습니다. 또한 여기에 댓글을 달고있는 더 광범위한 커뮤니티에서 상당한 지원을 받았습니다.

게다가 postfix 문법의 지지자들은 이것이 Rust를위한 최선의 경로라고 확신하는 것 같습니다. 이지지를 되돌리려면 지금까지 진행된 주장에 대한 몇 가지 깊은 문제 또는 설득력있는 반박이 필요할 것으로 보입니다.

이 점을 감안할 때,이 스레드를 자세히 살펴본 @withoutboats 와 다른 4 명의 lang 팀 구성원의 의견을 들어야 할 것 같습니다. 그들의 견해는 아마도이 스레드를 이끌 것입니다. 우려 사항이있는 경우이를 논의하는 것이 우선입니다. 그들이 접미사 구문의 경우를 확신한다면, 우리는 어느 것에 대한 합의를 찾을 수 있습니다.

죄송합니다. @Centril 이 이미 댓글을 으므로 청결을 위해 게시물을 숨길 것입니다.

@ivandardi 게시물의 목표 (1)를 감안할 때, 내 이해는 await가 여전히 키워드이므로 필드 액세스가 될 수 없다는 것입니다. loop {} 가 구조체 리터럴 표현식이 아닌 것과 같은 방식입니다. 그리고 더 분명하게 만들기 위해 강조 표시 될 것으로 예상합니다 (예 : https://github.com/rust-lang/rust-enhanced/issues/333이 Sublime에서 대기 중입니다).

내 한 가지 관심사는 await 구문을 다른 액세스처럼 보이게 만드는 것이 인식하지 못한 채 2015 버전 코드베이스에서 혼란을 일으킬 수 있다는 것입니다. (지정되지 않은 경우 2015가 기본값이며 다른 사람의 프로젝트를 여는 등) 2015 년 에디션에 await 필드가 없을 때 명확한 오류가있는 한 (있을 경우 경고) (Centril의 멋진 주장과 함께) 키워드 필드 (또는 방법)에 대한 개인적인 걱정을 없애줍니다.

아, 그리고 우리가 결정해야 할 한 가지는 rustfmt가 어떻게 포맷을 끝낼 것인지입니다.

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

1. await -확인
2. 일등석-수표
3. 체이닝-확인
4. Grepping-확인
5. 비시길-확인
6. 우선 순위-¹ 확인
7. 도트 파워-²check
8. 배우기 쉬움-³ 확인
9. 인체 공학적-점검

¹ 우선 순위 : await 뒤에 공백이 있으면 지연된 위치에서 명확하지 않습니다. 그러나 다음 코드에서와 정확히 동일합니다 : client.get("https://my_api").await_send()?.await_json()? . 모든 영어 사용자에게는 다른 모든 제안보다 훨씬 더 자연 스럽습니다.

²Dot power : 다음에 . , ? 또는 ; 를 입력 한 후 await 를 메서드 호출 왼쪽으로 이동하려면 IDE에 대한 추가 지원이 필요합니다. 구현하기가 너무 어렵지 않은 것 같습니다.

³ 배우기 쉬움 : 접두사 위치에서는 이미 프로그래머에게 익숙합니다. deffered 위치 에서 구문이 안정화 된 후에는 명백 할 것입니다.

그러나이 구문의 가장 큰 장점은 매우 일관성이 있다는 것입니다.

• 속성 액세스와 혼동 할 수 없습니다.
• ? 와 명백한 우선 순위가 있습니다.
• 항상 동일한 형식을 갖습니다.
• 인간의 언어와 일치합니다.
• 메서드 호출 체인에서 가변 수평 발생에 영향을받지 않습니다 *

접미사 변형을 사용하면 어떤 함수가 async 이고 수평 축에서 await 의 다음 발생 위치를 예측하기가 어렵습니다.

let res = client.get("https://my_api")
    .very_long_method_name(param, param, param).await?
    .short().await?;

지연된 변형의 경우 거의 항상 동일합니다.

let res = client.get("https://my_api")
    .await very_long_method_name(param, param, param)?
    .await short()?;

. 대기와 다음 메소드 호출 사이에? 처럼
get().await?.json()

2019 년 1 월 23 일 수요일, 05:06 I60R < [email protected] 작성 :

발 = 미래를 기다립니다;
let res = client.get ( "https : // my_api") .await send () ?. await json () ?;

1. 사용 대기-확인
2. 일등석-수표
3. 체이닝-확인
4. Grepping-확인
5. 비시길-확인
6. 우선 순위-¹ 확인
7. 도트 파워-²check
8. 배우기 쉬움-³ 확인
9. 인체 공학적-점검

---

¹ 우선 순위 : 공백은 지연된 위치에서 명확하지 않습니다. 그러나 그것은
다음 코드에서와 정확히 동일합니다. client.get ( "https : // my_api
") .await_send () ?. await_json () ?. 모든 영어 사용자의 경우 훨씬 더
다른 모든 제안보다 자연 스럽습니다.

²Dot 전원 : IDE로 이동하려면 추가 지원이 필요합니다.
이후 메서드 호출의 왼쪽. 또는? 다음에 입력됩니다. 너무 아닌 것 같습니다
구현하기 어렵다

³ 배우기 쉬움 : 접두사 위치에서는 이미 프로그래머에게 익숙합니다.
그리고 다른 위치 에서 그 구문이

안정된

하지만이 구문의 가장 큰 장점은
일관된:

• 속성 액세스와 혼동 할 수 없습니다.
• 그것은 명백한 우선 순위가?
• 항상 동일한 형식을 갖습니다.
• 인간의 언어와 일치합니다.
• 메서드 호출에서 가변 수평 발생에 영향을받지 않습니다.
  체인*

* 설명은 스포일러 아래에 숨겨져 있습니다.

접미사 변형을 사용하면 어떤 기능이 비동기인지 예측하기 어렵습니다.
가로 축에서 다음 번 await는 어디에 있습니까?

let res = client.get ( "https : // my_api")

.very_long_method_name(param, param, param).await?

.short().await?;

지연된 변형의 경우 거의 항상 동일합니다.

let res = client.get ( "https : // my_api")

.await very_long_method_name(param, param, param)?

.await short()?;

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/57640#issuecomment-456693759 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AIA8Ogyjc8LW6teZnXyzOCo31-0GPohTks5vGAoDgaJpZM4aBlba
.

우리는 또한 어떻게 rustfmt가 포맷을 끝낼 것인지 결정해야합니다.

그것은 https://github.com/rust-dev-tools/fmt-rfcs 의 도메인 이므로이 문제에 대해 주제에서 벗어난 것이라고 말할 것입니다. 어떤 고정 성과 우선 순위를 선택하든 일관된 무언가가있을 것이라고 확신합니다.

@ I60R

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

무료 기능 기능을 어떻게 찾을 수 있습니까? 내가 올바르게 읽고 있다면 실제로 접두사 await 입니다.

저는 이것이 우리가 C # 언어 팀의 경험을 너무 빨리 훼손해서는 안된다는 것을 보여줍니다. 마이크로 소프트는 사용성 연구에 많은 고려를하고 있으며, 우리는 여기에서 한 줄의 코드와 Rust가 다른 모든 언어와 다른 구문을 가질 수있을만큼 특별하다는 전제를 기반으로 결정을 내리고 있습니다. 저는 그 전제에 동의하지 않습니다. 위에서 언급 한 LINQ 및 확장 메서드가 C #에 널리 퍼져 있습니다.

그러나 .await 가 표면 구문이 아닐 때 .aw 를 시도하는 것은 저를 포함하여 많은 사람들에게 발생하지 않을 수 있습니다.

~ 다른 언어에 익숙한 사람에게는 이런 일이 발생하지 않을 것 같습니다. ~ 그 외에는 완료 팝업에 await 및 Future 메서드가 모두 포함될 것으로 예상하십니까?

[...] 그리고 우리는 여기서 한 줄의 코드와 Rust가 다른 모든 언어와 다른 구문을 가질 수있을만큼 특별하다는 전제를 기반으로 결정을 내리고 있습니다. 나는 그 전제에 동의하지 않는다 ...]

@lnicola 나는 당신과 다른 사람들이 그것을 놓친 경우를 지적하고 싶습니다 (많은 댓글에서 놓치기 쉽습니다) : https://github.com/rust-lang/rust/issues/57640#issuecomment -455846086

실제 생산 코드의 몇 가지 실제 예제.

위 의 @Centril 의 의견을 감안할 때 가장 강력한 경합의 접미사 옵션은 expr await postfix 키워드 구문과 expr.await postfix 필드 구문입니다 (아마도 postfix 메서드 구문은 아직 나오지 않았습니다).

postfix 키워드와 비교할 때 @Centril 은 postfix 필드가 "점의 힘"(IDE가 자동 완성으로 더 잘 제안 할 수 있음)의 이점을 제공하며 grep을 사용하여 사용 인스턴스를 찾기가 더 쉬울 수 있다고 주장합니다. 앞의 점은 주석에서 단어 사용과의 명확성을 제공합니다.

반대로 @cramertj 는 이러한 구문이 메소드 호출이나 필드 액세스가 아님을 분명히 해준다는 점에서 접미사 키워드 구문을 선호 한다고 주장 했습니다. @withoutboats 는 postfix 키워드가 가장 친숙한 postfix 옵션 이라고 주장 했습니다.

"점의 힘"과 관련하여 IDE는 여전히 await 를 점 다음에 완성으로 제공 할 수 있으며 완성이 선택되면 점을 제거하기 만하면됩니다. 충분히 스마트 한 IDE (예 : RLS 포함)는 Future를 알아 차리고 공백 뒤에 await 를 제공 할 수도 있습니다.

postfix 필드 및 메서드 옵션은 postfix 키워드와 비교하여 모호함으로 인해 이의를 제기 할 수있는 더 큰 표면적을 제공하는 것 같습니다. postfix 키워드에 대한 postfix 필드 / 메서드에 대한 지원 중 일부는 메소드 체인에 공백이 있다는 약간의 불편 함에서 비롯된 것으로 보이므로 postfix 키워드 ( foo.bar() await 대한 @valff 의 관찰 을 검토하고 참여해야합니다 foo.bar() await )는 일반화 된 유형 지정 ( foo.bar() : Result<Vec<_>, _> )보다 더 놀라운 것은 아닙니다. 두 경우 모두이 공백으로 구분 된 막간 이후에 연결이 계속됩니다.

@ivandardi , @lnicola ,

무료 함수 호출에 대한 예제가 누락되어 최근 댓글을 업데이트했습니다. 더 많은 예제를 원하면 이전 댓글 에서 마지막 스포일러를 참조 할 수 있습니다

future.await? 대 future await? 토론을

너무 많이 논의되지 않은 것은 시각적 인 그룹화 또는 메소드 체인의 grepping입니다.

(구문 강조를 위해 await 대신 match )

post(url).multipart(form).send().match?.error_for_status()?.json().match?

비교하자면

post(url).multipart(form).send() match?.error_for_status()?.json() match?

나는 시각에 대한 첫 번째 체인을 스캔 할 때 await 명확 I를 신속하게 식별 send().await? 우리가 결과 기다리고있는 것을 볼 send() .

그러나 두 번째 체인에서 await 시각적으로 스캔하면 먼저 await?.error_for_status() (가) 표시되고 이동, 아니요, 백업 한 다음 send() await 함께 연결해야합니다.

예, 이러한 동일한 인수 중 일부가 Generalized Type Ascription에 적용되지만 아직 허용되는 기능이 아닙니다. 어떤 의미에서는 타입 어 스크립 션을 좋아하지만 _general_ 표현 컨텍스트에서 (모호한) 괄호로 감싸 야한다고 생각합니다. 그래도이 토론에서는 주제를 벗어났습니다. 또한 코드베이스의 await 금액은 유형 지정 금액보다 훨씬 더 큰 변화가 있음을 명심하십시오.

Generalized Type Ascription은 고유 한 연산자 : 사용하여 유형을 할당 된 표현식에 바인딩합니다. 다른 이항 연산자와 마찬가지로이를 읽으면 두 표현식이 단일 트리임을 (시각적으로) 명확하게 알 수 있습니다. future await 에는 연산자가 없으며 첫 번째 가 키워드 인 경우를 제외하고 연산자로 구분되지 않은 두 이름을 거의 볼 수없는 습관에서 future_await 로 쉽게 착각 할 수 있습니다 (예외가 적용됩니다. 내가 접두사 구문을 선호한다고 말하지만 그렇지 않습니다).

원한다면 이것을 영어와 비교하십시오. 여기서 하이픈 ( - )은 별도의 것으로 쉽게 해석 될 수있는 단어를 시각적으로 그룹화하는 데 사용됩니다.

저는 이것이 우리가 C # 언어 팀의 경험을 너무 빨리 훼손해서는 안된다는 것을 보여줍니다.

나는 여기서 "너무 빠르다"와 "불신"이 공평하다고 생각하지 않는다. async / await RFC 자체에서 발생한 동일한 일이 여기에서 일어나고 있다고 생각합니다. 한 방향으로 수행 된 이유를 신중하게 고려하고 균형이 우리에게 동일한 방식으로 나오는지 여부를 확인합니다. C # 팀은 다음과 같이 명시 적으로 언급되기도합니다.

• 2394-async_await.md # polymorphic-return-a-non-factor-for-us
• 2394-async_await.md # hot-async-functions

await 의 아이디어는 실제로 미래가 아닌 결과를 원한다는 생각이었습니다.
따라서 await 구문은 'ref'구문과 비슷해야합니다.

let future = task()
그러나
let await result = task()

그래서 체인을 위해 당신은

task().chained_method(|future| { /* do something with future */ })

그러나

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

그들은 모두 체이닝과 잘 작동하며 모두 실제 필드 / 방법 / 매크로가 아닌 단점이 있습니다.
그러나 await 는 키워드로서 이미 특별한 것이기 때문에 더 특별하게 만들 필요가 없습니다.
가장 단순한 foo.await 선택해야합니다. () 및 !() 모두 여기에서 중복됩니다.

리고

- 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.

헉

await에 대한 첫 번째 체인을 시각적으로 스캔 할 때 send (). await를 명확하고 빠르게 식별합니다. send ()의 결과를 기다리고 있는지 확인합니다.

나는 미래가 어디에서 건설되고 어디를 기다려야하는지보기가 훨씬 더 쉽기 때문에 스페이스 버전을 더 좋아한다. 무슨 일이 일어나는지 보는 것이 훨씬 쉽습니다, IMHO

점 분리를 사용하면 메서드 호출과 매우 비슷해 보입니다. 코드 강조 표시는 많은 도움이되지 않으며 항상 사용할 수있는 것은 아닙니다.

마지막으로, 체인이 주요 사용 사례가 아니라고 생각합니다 ( ? 제외하지만 foo await? 는 가능한 한 명확합니다).

post(url).multipart(form).send().match?

vs

post(url).multipart(form).send() match?

후자가 훨씬 더 날씬해 보이는 곳.

따라서 future await 및 future.await 좁혔다면 마법의 "점"을 선택적으로 만들 수 있습니까? 사람들이 원하는 것을 선택할 수 있도록, 가장 중요한 것은 논쟁을 멈추고 앞으로 나아가는 것입니다!

선택적 구문을 사용하는 것은 해롭지 않습니다. Rust에는 그러한 예제가 많이 있습니다. 가장 잘 알려진 것은 마지막 sperator ( ; 또는 , 또는 (A,B,) 에서와 같이 마지막 항목 이후의 모든 것)는 대부분 선택 사항입니다. 나는 왜 우리가 점을 선택적으로 만들 수 없는지에 대한 강력한 이유를 보지 못했습니다.

Nightly에서이 작업을 수행하고 생태계가 자신에게 가장 적합한 것을 결정하도록하는 것이 좋은시기라고 생각합니다. 우리는 선호하는 스타일을 적용하기 위해 린트를 가질 수 있습니다.

그런 다음 Stable에 도착하기 전에 커뮤니티 사용을 검토하고 하나를 선택해야할지 아니면 둘 다 남겨 둘지 결정합니다.

나는 매크로가이 기능에 대해 충분히 일류라고 느끼지 않을 것이라는 개념에 완전히 동의하지 않으며 (처음에는 그러한 핵심 기능이라고 생각하지 않습니다) await!() 대한 이전 의견 을 다시 강조하고 싶습니다. await!() (접두사 또는 접미사에 관계없이) "실제 매크로"가 아니지만 결국 너무 많은 사람들이이 기능이 최대한 빨리 안정화되기를 원한다고 생각합니다. Rust에 잘 맞습니다.

어쨌든이 스레드를 하루 동안 잠그는 것은 많은 도움이되었으며 지금 구독을 취소하겠습니다. 내 요점 중 하나에 직접 답장하는 경우 언제든지 저를 언급하십시오.

. 구문에 대한 내 주장은 await 이 필드가 아니므로 필드처럼 보이지 않아야한다는 것입니다. 구문 강조 표시 및 굵은 글꼴을 사용하더라도 특수 필드 처럼 보이며 사용자 지정 서식도 . 뒤에 단어가 오는 것은 필드 액세스와 밀접하게 관련되어 있으므로 필드가 아니라는 것을 강조 할 수 없습니다.

더 나은 IDE 통합을 위해 . 구문을 사용할 이유가 없습니다. Intellij IDEA에서 사용할 수있는 접미사 완성 기능 과 같은 것을 사용하여 . 완성으로 다른 구문을 강화할 수 있기 때문입니다.

await 를 제어 흐름 키워드로 인식해야합니다. 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)
        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?;

이것은 또한 형식에 대한 @ivandardi 포인트에 대한 답변이 될 수 있습니다.

나는 postfix에 대한 이러한 모든 예제가 그것보다 더 반대 되기를 기다리고 있습니다. 긴 기다림 체인은 잘못된 느낌을 주므로 향후 결합 자에게 체인을 유지해야합니다.

비교 (구문 강조를 위해 match 를 await 사용) :

post(url)?.multipart(form).send()?.match?.error_for_status()?.json().match?

...에

let value = await post(url)?.multipart(form).send()?.error_for_status()
                 .and_then(|resp| resp.json()) // and then parse JSON

// now handle errors

중간에 기다림이 부족한 것을 아시나요? 연결은 일반적으로 더 나은 API 설계로 해결할 수 있기 때문입니다. send() 가 200이 아닌 상태 메시지를 하드 오류로 변환하는 것과 같이 추가 메서드가있는 사용자 지정 Future를 반환하면 추가 대기가 필요하지 않습니다. 지금 당장 적어도 reqwest 에서는 제자리에서 실행되고 새로운 미래가 아닌 평범한 Result 생성하는 것 같습니다. 여기에서 문제가 발생합니다.

체이닝 awaits는 내 의견으로는 강력한 코드 냄새 이며 .await 또는 .await() 는 많은 신규 사용자를 혼란스럽게 할 것입니다. .await 특히 변수 멤버 액세스가 마술처럼 특별한 동작을 할 수있는 Python 또는 PHP에서 나온 것처럼 느껴집니다.

await 는 "계속하기 전에 우리는 이것을 기다립니다"라고 말하는 것처럼 "그리고 나서 이것을 기다립니다"라고 말하는 것처럼 명백해야합니다. 후자는 말 그대로 and_then 결합 자입니다.

그것에 대해 생각하는 또 다른 잠재적 인 방법은 async / await 표현식과 퓨처를 반복자처럼 고려하는 것입니다. 그들은 모두 게으른 많은 상태를 가질 수 있고, (구문을 종료 할 수 있습니다 for-in 반복자를 들어, await 선물에 대한). 반복자가 여기있는 것처럼 정규 표현식으로 연결하는 구문 확장을 제안하지 않겠습니까? 그들은 연결을 위해 결합자를 사용하고 비동기 작업 / 미래는 동일한 작업을 수행해야하며 한 번만 종료됩니다. 꽤 잘 작동합니다.

마지막으로 가장 중요한 것은 함수의 처음 몇 개의 들여 쓰기를 수직으로 훑어보고 비동기 작업이 발생하는 위치를 명확하게 볼 수 있기를 원한다는 것입니다. 내 비전은 그다지 좋지 않으며, 라인의 끝에서 기다리거나 중간에 갇혀 있으면 일이 훨씬 더 어려워 져서 원시 선물을 완전히 유지할 수 있습니다.

누구나 댓글을 달기 전에이 블로그 게시물을 읽어 보시기 바랍니다 .

Async / await는 편리함이 아닙니다 . 결합자를 피하는 것이 아닙니다 .

결합 자로 할 수없는 새로운 것을 가능하게하는 것입니다.

따라서 "대신 결합자를 사용하자"라는 제안은 주제를 벗어난 것이며 다른 곳에서 논의해야합니다.

중간에 기다림이 부족한 것을 아시나요? 연결은 일반적으로 더 나은 API 설계로 해결할 수 있기 때문입니다.

실제 비동기 예제에서는 예쁜 체인을 얻지 못할 것입니다. 실제 예 :

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)
})

조합기는 여기서 도움이되지 않습니다. 중첩은 제거 할 수 있지만 쉽지 않습니다 (두 번 시도했지만 실패했습니다). 끝에 Either:A(Either:A(Either:A(...))) 톤이 있습니다.

OTOH 는 async / await로 쉽게 해결됩니다 .

@Pauan 이 async/await 은 (는) 비슷해 보이지 않아야합니다. 그렇다면 괜찮습니다. 고려해야 할 더 중요한 사항이 있습니다.

내 댓글에 반대 투표를한다고해서 결합자가 더 편리해지지는 않습니다.

type ascription comment를 읽으면서 await 와 결합하여 어떻게 보일지 생각하고있었습니다. 일부 사람들이 .await 또는 .await() 를 혼동하는 멤버 필드 / 메소드 액세스로 예약 한 경우 일반적인 "ascription"구문이 옵션이 될 수 있는지 궁금합니다 (예 : "give me what await 반환 ").

구문 강조를 위해 await 에 yield 사용

let result = connection.fetch("url"):yield?.collect_async():yield?;

유형 지정과 결합됩니다. 예 :

let result = connection.fetch("url") : yield?
    .collect_async() : yield Vec<u64>?;

장점 : 여전히 멋지게 보입니다 (IMHO), 필드 / 메소드 액세스와 구문이 다릅니다.
단점 : 유형 지정 (?)과 잠재적 인 충돌, 이론적으로 다중 지정 가능 :

foo():yield:yield

편집 : 결합 된 예에서 2 개의 비문을 사용하는 것이 더 논리적이라고 생각했습니다.

let result = connection.fetch("url") : yield?
    .collect_async() : yield : Vec<u64>?;

@Pauan 해당 블로그 게시물을 과도하게 적용하는 것은 부적절합니다. 결합자는 설명하는 문제를 피하기 위해 await 구문과 함께 적용 할 수 있습니다.

핵심 문제는 항상 생성 가능한 퓨처가 'static 여야한다는 것이었지만, 해당 결합 자에서 참조로 변수를 캡처 한 경우 'static 가 아닌 'static 당신이하지에있는 FN 미래하면 비동기가되지 않습니다 'static . 따라서 다음과 같이 할 수 있습니다.

```녹
// 슬라이스 : & [T]

let x = await future.and_then (| i | if slice.contains (i) {async_fn (slice)});

그래서 저는 전혀 주석을 달지 않을 계획 이었지만 비동기 코드를 많이 작성하지는 않지만 여전히 읽어야하는 사람의 메모를 추가하고 싶었습니다.

• 접두사 await 은 눈에 띄기 훨씬 쉽습니다. 이것은 당신이 그것을 기대할 때 ( async fn 내부) 또는 외부 (일부 매크로 본문의 표현에서) 둘 다입니다.
• await 접미어는 다른 키워드가 거의 또는 전혀없는 체인에서 잘 눈에 띄는 키워드가 될 수 있습니다. 그러나 클로저 또는 다른 제어 구조와 유사하게되면 awaits 는 눈에 띄지 않게되고 간과하기 쉬워집니다.
• .await 의사 필드가 매우 이상하다고 생각합니다. 나에게 중요한 다른 분야와는 전혀 다릅니다.
• IDE 감지 및 구문 강조 표시에 의존하는 것이 좋은 생각인지 잘 모르겠습니다. 구문 강조 표시를 사용할 수 없을 때 가독성이 좋습니다. 게다가 문법을 복잡하게 만드는 것에 대한 최근 논의와 도구에 대한 문제를 해결하기 위해 IDE / 편집기에 의존하는 것은 좋은 생각이 아닐 수 있습니다.

나는 await!() 매크로가 "일류라고 느끼지 않는다"는 감정을 공유하지 않습니다. 매크로는 Rust에서 완전히 일류 시민 입니다. 또한 "사용자 코드에서 구문 발명"을 위해서만 존재하는 것은 아닙니다. 많은 "내장"매크로는 사용자 정의가 아니며 단순한 구문상의 이유로 존재하지 않습니다. format!() 는 컴파일러에게 정적으로 형식을 검사하는 형식 문자열의 기능을 제공합니다. include_bytes!() 또한 사용자 정의가 아니며 단순한 구문상의 이유 때문에 존재하지 않습니다. 다시 말하지만 컴파일러 내부에서 특별한 작업을 수행 할 수 없기 때문에 구문 확장이 필요하기 때문에 매크로입니다. 핵심 언어 기능으로 추가하지 않고 다른 방식으로 합리적으로 작성해야합니다.

그리고 이것은 일종의 내 요점입니다. 매크로는 균일하고 놀라운 방법으로 컴파일러 마법을 도입하고 숨기는 완벽한 방법입니다

그래서 저는 특별한 키워드의 필요성을 전혀 알지 못합니다. 즉, 키워드가 되려면 그저 그저 그저 키워드 여야합니다. 필드로 위장한 동기를 정말로 이해하지 못합니다. 그것은 잘못된 것처럼 보이며 필드 액세스가 아니며 원격으로 필드 액세스 와 도

@ H2CO3 await! 매크로는 다음 두 가지 속성을 제외하고 모든 바람직한 방식으로 좋습니다.

1. 추가 중괄호는 당신이 아직 수천 개를 기다릴 때 정말 짜증납니다. Rust는 같은 이유로 if/while/... 블록에서 중괄호를 제거했습니다. 중요하지 않은 ATM으로 보일 수 있지만 실제로는 그렇습니다.
2. async 가 키워드 인 비대칭. Async는 메서드 본문에 하나의 매크로를 허용하는 것보다 더 큰 작업을 수행해야합니다. 그렇지 않으면 함수 위에 #[async] 속성이 될 수 있습니다. 속성이 블록 등에서 사용할 수 없다는 것을 이해하지만 await 키워드 발생에 대한 기대치를 제공

그렇지 않으면 함수 위에 #[async] 속성이 될 수 있습니다.

오랫동안 그랬고, 그것이 진행되는 것을 보니 유감입니다. #[async] 속성은 완벽하게 작동했지만 이제는 속성과 유사한 절차 적 매크로가 안정적으로 작동하는 반면 다른 키워드를 도입하고 있습니다. 여전히 알려진 경우에도 구문 적으로나 의미 적으로 나머지 언어와도 일치합니다. (그리고 특별히 처리) 컴파일러에 의해.

@ H2CO3 사용자 관점에서 await 를 매크로 로 사용 하는 목적이나 이점은 무엇입니까? 내부적으로 프로그램 제어 흐름을 변경하는 내장 매크로가 있습니까?

@ I60R 장점은 나머지 언어와의 통일성이므로 다른 키워드에 대해 걱정할 필요가 없으며 자체적으로 가져 오는 모든 짐이 있습니다. 예를 들어 우선 순위와 그룹화는 매크로 호출에서 분명합니다.

두 번째 부분이 왜 관련이 있는지 모르겠습니다. 새로운 것을 수행하는 내장 매크로가있을 수 없습니까? 사실 거의 모든 내장 매크로가 컴파일러 지원 없이는 (합리적으로 / 효율적으로 / 등) 달성 할 수없는 "이상한"일을한다고 생각합니다. await!() 는 이와 관련하여 새로운 침입자가 아닙니다.

이전에 암시 적 await를 제안했고 최근에는 non-chainable await를 제안했습니다.

커뮤니티는 명시 적 기다림을 매우 강력하게 선호하는 것 같습니다 (변경되기를 원하지만…). 그러나 명시 성의 세분성은 상용구를 생성하는 것입니다 (즉, 동일한 표현식에서 여러 번 필요하면 상용구가 생성되는 것 같습니다).

[ 경고 : 다음과 같은 제안은 논란의 여지가 있지만 진심으로 기회를주십시오.]

대부분의 커뮤니티가 타협하고 "부분 암시 적 대기"를 허용하는지 궁금합니다. 식 체인 당 한 번 읽는 것이 충분히 명시 적일까요?

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

이것은 값 구조화와 비슷한 것으로, 이것을 표현 구조화라고 부릅니다.

// 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-26395496ff0c677f1051cf90a7c11b94



```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?);

또한 핵심 아이디어의 다른 구현에 만족할 것입니다. "표현 체인 당 한 번 읽는 것이 충분히 명시적일 가능성이 높습니다." 상용구를 줄이면서 모든 사람에게 가장 친숙한 접두사 기반 구문으로 연결을 가능하게하기 때문입니다.

@yazaddaruvala 위 의 경고가 있었 으니 조심하세요.

대부분의 커뮤니티가 타협하고 "부분 암시 적 대기"를 허용하는지 궁금합니다. 식 체인 당 한 번 읽는 것이 충분히 명시 적일까요?

1. 나는 대부분의 커뮤니티가 부분적으로 암시적인 것을 원하지 않는다고 생각합니다. Rust 네이티브 접근 방식은 "모두 명시 적"에 가깝습니다. 캐스트 u8-> u32도 명시 적으로 수행됩니다.
2. 더 복잡한 시나리오에서는 잘 작동하지 않습니다. 컴파일러는 Vec<Future> 무엇을해야합니까?

await response = client.get("https://my_api").send()?.json()?.parse_as::<Vec<String>>()?.map(|x| client.get(x))?;

모든 중첩 된 호출에 대해 await 을 수행해야합니까? 좋아, 우리는 아마도 한 줄의 코드에 대해 await 작업을 할 수있을 것이다 (그래서 중첩 된 mapFunc 는 기다리지 않을 것이다). 그러나이 동작을 깨는 것은 너무 쉽다. await가 하나의 코드 라인에 대해 작동하면 "extract value"와 같은 리팩토링으로 인해 중단됩니다.

안녕하세요.

나는 당신이 추구하는 것이 ? 보다 우선하는 접두사 await라는 것을 이해합니까? let 키워드 대신 await를 사용하여 컨텍스트를 변경하여 모든 impl Future <_ i = "7"> await와 함께 반환 하시겠습니까?

아래의 세 문장이 동일 함을 의미합니다.

// foo.bar() -> Result<impl Future<_>, _>>
let a = await foo.bar()?;
let a = await (foo.bar()?);
await a = foo.bar()?;

그리고 아래 두 문장은 동일합니다.

// foo.bar() -> impl Future<Result<_, _>>
await a = foo.bar()?;
let a = await (foo.bar())?;

구문이 이상적 일지는 모르겠지만 "암시 적 컨텍스트 대기"로 변경되는 키워드가 있으면 접두사 키워드의 문제가 덜 문제가됩니다. 동시에 필요할 때 await가 사용되는 위치를보다 세밀하게 제어 할 수 있습니다.

내 생각에, 짧은 한 줄 접두사 await는 다른 많은 프로그래밍 언어 및 많은 인간 언어와 유사하다는 이점이 있습니다. 결국 await가 접미사 여야한다고 결정했다면 가끔 Await!() 매크로 (또는 유사한 형식이 키워드와 충돌하지 않는)를 사용하게 될 것입니다. 영어 문장 구조에 대한 깊이있는 익숙 함은 코드 읽기 / 쓰기의 정신적 오버 헤드를 줄이는 데 도움이됩니다. 더 긴 연쇄 표현에 대한 접미사 형식에는 명확한 가치가 있지만, 객관적 사실에 기반하지 않은 명시 적 관점은 접두사의 인간 복잡성이 구어에 의해 보조되기 때문에 하나의 형식 만 갖는 단순성 이점이 있다는 것입니다. 둘 다 갖는 잠재적 인 코드 명확성을 능가하는 것은 아닙니다. 프로그래머가 적어도 현재 코드 덩어리에 가장 적합한 것을 선택하도록 신뢰한다고 가정합니다.

헉

나는 대부분의 커뮤니티가 부분적으로 암시적인 것을 원하지 않는다고 생각합니다. Rust 네이티브 접근 방식은 "모두 명시 적"에 가깝습니다.

나는 그것을 같은 방식으로 보지 않는다. 나는 그것이 항상 명시적이고 암시적인 타협이라고 봅니다. 예를 들면 :

• 함수 범위에는 변수 유형이 필요합니다.
  
  
  
  • 변수 유형은 로컬 범위 내에서 암시적일 수 있습니다.
  
  
  • Clousure 컨텍스트는 암시 적입니다.
  
  
  • 이미 지역 변수에 대해 추론 할 수 있다는 점을 감안할 때.
  
  
• 대출 검사기를 돕기 위해서는 평생이 필요합니다.
  
  
  
  • 그러나 로컬 범위 내에서 추론 할 수 있습니다.
  
  
  • 함수 수준에서 수명은 모두 동일한 값일 때 명시적일 필요가 없습니다.
  
  
• 더 많은 것이 있다고 확신합니다.

연결의 모든 이점과 함께 식 / 문당 한 번만 await 사용하는 것은 명시 적 및 감소 된 상용구 사이의 매우 합리적인 절충안입니다.

더 복잡한 시나리오에서는 잘 작동하지 않습니다. Vec으로 컴파일러가해야 할 일?

await response = client.get("https://my_api").send()?.json()?.parse_as::<Vec<String>>()?.map(|x| client.get(x))?;

나는 컴파일러가 오류를해야한다고 주장한다. 추론 할 수없는 엄청난 유형의 차이가 있습니다. 한편, Vec<impl Future> 를 사용한 예제는이 스레드의 구문으로 해결되지 않습니다.

// 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])?;

나는 Vec<impl Future> 가 형편없는 예라고 주장하거나, 제안 된 모든 구문을 동일한 표준으로 유지해야합니다. 한편, 내가 제안한 "partial-implicit await"구문은 일반적인 접미사 또는 접두사 await let (a, b) = (client.get("a") await?, client.get("b") await?); 사용하는 await (a, b) = (client.get("a")?, client.get("b")?); 와 같은 더 복잡한 시나리오에 대한 현재 제안보다 더 잘 작동합니다. -암시 적 버전은 컴파일러가 적절하게 고려하여 동시에 실행할 수 있습니다 (원래 게시물에 표시된 것처럼).

2011 년에 C #의 async 기능이 아직 테스트 중이었을 때 저는 await 가 접두사 연산자인지 물었고 C # Language PM으로부터 응답을 받았습니다. Rust가 접두사 연산자를 사용해야하는지에 대한 논의가 있었기 때문에 여기에 그 응답을 게시하는 것이 중요 할 것이라고 생각했습니다. 왜 'await'가 접미사 연산자 대신 접두사 연산자입니까? :

당신이 상상할 수 있듯이, await 표현식의 구문은 우리가 지금 거기에 무엇이 있는지 결정하기 전에 큰 토론의 포인트였습니다 :-). 그러나 우리는 접미사 연산자를 많이 고려하지 않았습니다. 접미사 (HP caluclators 및 프로그래밍 언어 Forth 참조)에 대해 원칙적으로는 더 간단하고 실제로는 접근하기 어렵거나 가독성이 떨어집니다. 어쩌면 수학 표기법이 우리를 어릴 때 세뇌하는 방식 일 수도 있습니다 ...

우리는 접두사 연산자 (말 그대로 명령형- "do this!")가 가장 직관적이라는 것을 확실히 알았습니다. 대부분의 단항 연산자는 이미 접두사이며 await가 그에 맞는 것처럼 보입니다. 예, 복잡한 표현식에서 빠져 나가지 만, 예를 들어 함수 응용 프로그램이 접미사가 아니기 때문에 일반적으로 평가 순서도 마찬가지입니다. 먼저 인수 (오른쪽에 있음)를 평가 한 다음 함수 (왼쪽에 있음)를 호출합니다. 예, C #의 함수 응용 프로그램 구문에는 이미 괄호가 내장되어있는 반면 await의 경우 일반적으로 삭제할 수 있다는 점에 차이가 있습니다.

내가 await에 대해 광범위하게보고 채택한 것은 많은 임시 변수를 사용하는 스타일입니다. 나는 선호하는 경향이 있습니다

var bResult = await A().BAsync();
var dResult = await bResult.C().DAsync();
dResult.E()

또는 그런 것. 일반적으로 나는 보통 가장 단순한 표현을 제외하고는 하나 이상의 await를 피하고 (즉, 모두 동일한 함수 나 연산자에 대한 인수입니다. 아마 괜찮습니다) await 표현을 괄호로 묶지 않고 두 작업 모두에 추가 로컬을 사용하는 것을 선호합니다. .

말이 되나?

Mads Torgersen, C # 언어 PM

C # 개발자로서의 개인적인 경험은 구문이 여러 문 스타일을 사용하도록 유도하고 이로 인해 비동기 코드가 동기 코드보다 읽고 쓰기가 훨씬 더 어색하다는 것입니다.

안녕하세요.

나는 그것을 같은 방식으로 보지 않는다. 항상 명시적이고 암시적인 타협이라고 생각합니다.

여전히 명시 적입니다. 주제 btw에 대한 좋은 기사를 링크 할 수 있습니다.

나는 컴파일러가 오류를해야한다고 주장한다. 추론 할 수없는 엄청난 유형의 차이가 있습니다. 한편 Vec의 예는이 스레드의 구문으로 해결되지 않습니다.

왜 그것이 오류라고 생각합니까? Vec<impl future> ) 갖게되어 기쁩니다. 그러면 함께 참여할 수 있습니다. 이유없이 추가 제한을 제안합니다.

나는 Vec이좋지 않은 예이거나 제안 된 모든 구문을 동일한 표준으로 유지해야합니다.

우리는 모든 사건을 조사해야합니다. "아, 알다시피, 아무도이 글을 쓰지 않기 때문에"엣지 케이스를 무시할 수는 없습니다. 언어 디자인은 주로 엣지 케이스에 관한 것입니다.

@chescock 동의하지만 전에 말했듯이 Rust는 C #과 매우 큰 차이가 있습니다. C #에서는 절대로 (await FooAsync()).Bar() 를 쓰지 않습니다. 하지만 Rust에서는 그렇게합니다. 그리고 저는 ? 에 대해 이야기하고 있습니다. C #에서는 비동기 호출을 통해 전파되는 암시 적 예외가 있습니다. 그러나 Rust에서는 기다린 후에 명시 적으로 함수 결과에 ? 를 써야합니다.

물론 사용자에게

let foo = await bar();
let bar = await foo?.baz();
let bar = bar?;

그러나 그것은보다 훨씬 더 이상합니다

let foo = await? bar();
let bar = await? foo.baz();

훨씬 더 좋아 보이지만 await 및 ? doint (await expr)? 새로운 조합을 도입해야합니다. 또한 다른 연산자가 있다면 await?&@# 하고 모든 조합이 모두 작동하도록 할 수 있습니다. 약간 복잡해 보입니다.

그러나 우리는 await를 접미사로 배치 할 수 있으며 자연스럽게 현재 언어에 맞을 것입니다.

let foo = bar() await?;
let bar = foo.baz() await?;

이제 await? 는 두 개의 분리 된 토큰이지만 함께 작동합니다. await?&@# 가질 수 있으며 컴파일러 자체에 해킹하지 않아도됩니다.

물론 접두사 방식보다 약간 이상해 보이지만 Rust / C # 차이에 관한 것입니다. 분리 된 키워드를 가질 가능성이있는 명시 적 대기 구문이 필요한지 확인하기 위해 C # 경험을 사용할 수 있지만, 맹목적으로 같은 방식을 따르고 Rust / C # 차이점을 무시해서는 안됩니다.

나는 오랫동안 접두사 await 의 지지자 였고 C # 언어 개발자를 주제에 초대하기도했지만 (그래서 2011 년 이후의 정보보다 더 새로운 정보를 얻었습니다 😄), 이제는 await 접두사라고 생각합니다.

야간이 있다는 것을 잊지 마십시오. 더 나은 방법을 찾으면 나중에 다시 작업 할 수 있습니다.

다음과 같은 조합으로 두 세계의 장점을 모두 얻을 수 있다는 생각이 들었습니다.

• 접두사 async 키워드
• 일반적인 접미사 매크로 기능

이것은 컴파일러 마법없이 .await!() 접미사 매크로를 구현할 수 있도록합니다.

지금 당장 접미사 .await!() 매크로에는 컴파일러 마법이 필요합니다. 그러나 await 키워드의 접두사 변형이 안정화되면 더 이상 사실이 아닙니다. 접미사 .await!() 매크로는 인수 (표현식)를 접두사로하는 매크로로 간단하게 구현할 수 있습니다. await 키워드로 모든 것을 괄호로 묶었습니다.

이 접근 방식의 장점 :

• 접두사 await 키워드를 사용할 수 있으며 다른 언어에서 해당 구문에 익숙한 사용자가 액세스 할 수 있습니다.
• 접두사 async 키워드는 표현식의 비동기 특성을 "눈에 띄게"만드는 것이 바람직한 경우에 사용할 수 있습니다.
• 연결 상황이나 접두사 구문이 어색한 다른 상황에서 사용할 수있는 접미사 변형 .await!() 가 있습니다.
• postfix 변형에 대한 (잠재적으로 예상치 못한) 컴파일러 마법이 필요하지 않습니다 (그렇지 않으면 postfix 필드, 메서드 또는 매크로 옵션에 대한 문제가 됨).
• Postfix 매크로는 유사한 이유로 postfix 매크로 구문이 공동으로 필요한 다른 상황 (예 .or_else!(continue) )에서도 사용할 수 있습니다 (그렇지 않으면 앞의 표현식을 어색하고 읽을 수없는 방식으로 래핑해야 함).
• 접두사 await 키워드는 접미사 매크로 구현을 기다릴 필요없이 상대적으로 빠르게 안정화 될 수 있습니다 (생태계가 개발 될 수 있도록 허용). 그러나 중장기 적으로 우리는 기다릴 수있는 접미사 구문의 가능성을 열어 둘 것입니다.

@nicoburns , @ H2CO3 ,

await!() 및 .or_else!(continue) 와 같은 제어 흐름 연산자를 매크로로 구현해서는 안됩니다 . 사용자 관점 에서는 그렇게 할 의미있는 이유가 없기 때문입니다. 어쨌든 두 형태 모두 사용자는 똑같은 기능을 가지고 있고 둘 다 배워야합니다. 그러나 이러한 기능이 매크로로 구현된다면 사용자는 추가적으로 왜 정확히 이런 방식으로 구현

. 이전에 await . 를 추가 할 때와 똑같은 대답입니다. 필요하지 않습니다. 매크로는 일류 제어 흐름을 모방 할 수 없습니다. 형태가 다르고 사용 사례가 다르며 강조 표시가 다르며 작동 방식이 다르며 완전히 다르게 인식됩니다.

.await!() 및 .or_else!(continue) 기능에는 await 키워드 및 none -coalescing 연산자와 같은 아름다운 구문을 사용하는 적절하고 인체 공학적인 솔루션이 있습니다. 우리는 일반적이고 거의 사용되지 않으며 추악한 접미사 매크로 대신에 구현하는 것을 선호해야합니다.

매크로를 사용할 이유가 없습니다. format!() 와 같은 복잡한 것이 없기 때문에 include_bytes!() 와 같이 거의 사용되지 않는 것도없고, 사용자 지정 DSL도없고, 사용자 코드에서 중복을 제거 할 필요가 없습니다. vararg와 같은 구문이 필요하지 않으며 다르게 보이는 것이 필요 없으며 가능하기 때문에 이런 식으로 사용할 수 없습니다.

제어 흐름 연산자를 매크로로 구현해서는 안됩니다. 사용자 관점에서는 그렇게 할 의미있는 이유가 없기 때문입니다.

try!() 는 매크로로 구현되었습니다. 그것에 대한 완벽한 이유가있었습니다.

await 매크로를 만드는 이유가 무엇인지 이미 설명했습니다. 기존 기능이 목표를 달성 할 수 있다면 새 언어 요소가 필요하지 않습니다.

format!() 와 같은 복잡한 것은 없습니다

나는 다른 점을 간청한다. format!() 는 복잡함이 아니라 컴파일 타임 검사에 관한 것이다. 컴파일 타임 검사가 아니었다면 함수일 수 있습니다.

그건 그렇고 나는 그것이 접미사 매크로 여야한다고 제안하지 않았습니다. (그럴 수 없다고 생각합니다.)

두 기능 모두 아름다운 구문을 갖춘 적절하고 인체 공학적인 솔루션이 있습니다.

모든 단일 함수 호출, 흐름 제어 표현식 또는 사소한 편의 기능에 고유 한 매우 특별한 구문을 제공해서는 안됩니다. 그 결과 아무 이유없이 구문이 가득한 부풀어 오른 언어가 나오고 "아름다운"과는 정반대입니다.

(나는 내가 할 수있는 것을 말했고, 나는 더 이상 질문의이 측면에 답하지 않을 것입니다.)

뿡 빵뀨

다음과 같은 조합으로 두 세계의 장점을 모두 얻을 수 있다는 생각이 들었습니다.

• 접두사 await 키워드
• 일반적인 접미사 매크로 기능

이것은 await 현재의 실제 키워드가 아닌 문맥 키워드로 만드는 것을 수반합니다. 그렇게해서는 안된다고 생각합니다.

이것은 컴파일러 마법없이 .await!() 접미사 매크로를 구현할 수 있도록합니다.

이는 foo await 또는 foo.await (특히 후자)보다 구현 측면에서 더 복잡한 솔루션입니다. 그것과 마찬가지로 여전히 "마법"이 있습니다. 방금 회계 책정을 하셨습니다.

이 접근 방식의 장점 :

• 접두사 await 키워드를 사용할 수 있으며 다른 언어에서 해당 구문에 익숙한 사용자가 액세스 할 수 있습니다.

나중에 .await!() 를 추가 할 경우 사용자에게 더 많은 정보를 제공하고 ( await foo 및 foo.await!() ) 이제 사용자는 "어떤 것을 사용해야하는지 언제..". 이는 단일 솔루션이 사용하는 것처럼 foo await 또는 foo.await 보다 복잡성 예산을 더 많이 사용하는 것 같습니다.

• Postfix 매크로는 유사한 이유로 postfix 매크로 구문이 공동으로 필요한 다른 상황 (예 .or_else!(continue) )에서도 사용할 수 있습니다 (그렇지 않으면 앞의 표현식이 어색하고 읽을 수없는 방식으로 래핑되어야 함).

접미사 매크로는 가치가 있으며 언어에 추가되어야한다고 생각합니다. 그러나 이것이 await ing에 사용되어야한다는 의미는 아닙니다. 언급했듯이 .or_else!(continue) 및 접미사 매크로가 유용한 다른 많은 곳이 있습니다.

• 접두사 await 키워드는 접미사 매크로 구현을 기다릴 필요없이 상대적으로 빠르게 안정화 될 수 있습니다 (생태계가 개발 될 수 있도록 허용). 그러나 중장기 적으로 우리는 기다릴 수있는 접미사 구문의 가능성을 열어 둘 것입니다.

나는 "개방 된 가능성을 남겨두기"에 가치가 없다고 본다. 구성, IDE 경험 등에 대한 접미사의 가치는 오늘날 알려져 있습니다. 저는 "오늘 await foo 안정화에 관심이 없으며 내일 foo.await!() 에 합의에 도달 할 수 있기를 바랍니다 ."

헉

try!() 는 매크로로 구현되었습니다. 그것에 대한 완벽한 이유가있었습니다.

try!(..) 는 더 이상 사용되지 않습니다. 즉, 특히 접미사가 아니기 때문에 언어에 적합하지 않다고 생각했습니다. 우리가 하지 말아야 할 일이 try!(..) 는 컴파일러의 지원없이 정의됩니다 .

그건 그렇고 나는 그것이 접미사 매크로 여야한다고 제안하지 않았습니다. (그럴 수 없다고 생각합니다.)

await 는 "every single .."이 아닙니다. 특히 사소한 편의 기능이 아닙니다. 오히려 추가되는 주요 언어 기능입니다.

헉

게다가 문법을 복잡하게 만드는 것에 대한 최근 논의와 도구에 대한 문제를 해결하기 위해 IDE / 편집기에 의존하는 것은 좋은 생각이 아닐 수 있습니다.

foo.await 구문은 Rust를 잘 지원하는 편집기라면 이미 .ident 형식을 이해하고 있기 때문에 툴링 문제를 줄이기 위한 것입니다. 편집자는 키워드 목록에 await 를 추가하기 만하면됩니다. 또한 좋은 IDE에는 이미 . 기반의 코드 완성 기능이 있으므로 사용자가 . 입력 할 때 첫 번째 제안으로 await 를 제공하도록 RLS (또는 동등한 항목 ...)를 확장하는 것이 더 간단 해 보입니다 . my_future 이후

문법을 복잡으로서, .await 실제로 가장 가능성지지 주어진 문법 복잡하다 .await 본질적으로 해석되는 구문 .$ident 에 erroring하지 다음과 ident == keywords::Await.name() .

foo.await 구문은 Rust를 잘 지원하는 편집기라면 이미 .ident 형식을 이해하고 있기 때문에 툴링 문제를 줄이기위한 것입니다. 편집자는 키워드 목록에 await를 추가하기 만하면됩니다. 또한 좋은 IDE에는 이미. -따라서 사용자가을 입력 할 때 첫 번째 제안으로 await를 제공하도록 RLS (또는 이와 동등한 것 ...)를 확장하는 것이 더 간단 해 보입니다. my_future 이후.

문법 토론과 상충됩니다. 그리고 문제는 단지 지금이 아니라 5 년, 10 년, 20 년 후, 몇 번의 에디션을 거쳐야합니다. 하지만 알아 차리 셨기를 바라며, 키워드가 강조 표시 되더라도 다른 키워드가 포함되면 대기 포인트가 눈에 띄지 않을 수 있다는 점도 언급합니다.

문법을 복잡하게 만드는 것과 관련하여 .await는 구문에서 .await를 지원하는 것이 본질적으로. $ ident를 구문 분석하고 ident == 키워드 :: Await.name ()에 오류가 없다는 점을 감안할 때 실제로 문법을 복잡하게 만들 가능성이 가장 적습니다.

나는 이미 문법에 의해 완전히 지원되기 때문에 명예가 await!(future) 있다고 생각합니다.

@Centril try! 는 ? 연산자가 더 많은 작업을 수행 할 수 있기 때문에 결국 중복되었습니다. "언어에 부적합"하지 않습니다. 하지만 당신은 그것을 좋아하지 않을 수도 있습니다. 하지만 저에게 그것은 실제로 Rust가 발명 한 최고의 것 중 하나이며 판매 포인트 중 하나였습니다. 그리고 컴파일러 지원없이 구현된다는 것을 알고 있지만 제어 흐름을 수행하는지 여부를 논의 할 때 이것이 얼마나 관련이 있는지 알 수 없습니다. 상관없이 그렇습니다.

await는 "every single .."이 아닙니다.

그러나 여기에 언급 된 다른 것 (예 : or_else )은 어쨌든 내 요점은 여전히 ​​주요 기능에 적용됩니다. 구문을 추가하기 위해 구문을 추가하는 것은 이점이 아니므로 더 일반적인 경우에 이미 작동하는 것이있을 때마다 새로운 표기법을 만드는 것보다 선호해야합니다. (매크로에 대한 또 다른 주장은 "그들은 접미사가 아닙니다"라는 것입니다. 자체 접미사 연산자를 기다리는 것의 이점이 비용을 정당화 할만큼 충분히 높다고 생각하지 않습니다. 중첩 함수 호출에서 살아 남았습니다. 두 개의 중첩 매크로를 작성한 후에도 똑같이 괜찮습니다.)

Wed, Jan 23, 2019 at 09:59:36 PM +0000, Mazdak Farrokhzad write :

• Postfix 매크로는 유사한 이유로 postfix 매크로 구문이 필요한 다른 상황에서도 사용할 수 있습니다 (예 .or_else!(continue) ).

접미사 매크로는 가치가 있으며 언어에 추가되어야한다고 생각합니다. 그러나 이것이 await ing에 사용되어야한다는 의미는 아닙니다. 언급했듯이 .or_else!(continue) 및 접미사 매크로가 유용한 다른 많은 곳이 있습니다.

.await!() 를 사용하는 주된 이유는 매크로처럼 보이기 때문에
제어 흐름에 영향을 미칠 수 있음이 분명합니다.

.await 는 필드 액세스처럼 보이고 .await() 는 함수처럼 보입니다.
필드 액세스 나 함수 호출 모두 제어에 영향을 줄 수 없습니다.
흐름. .await!() 는 매크로처럼 보이며 매크로 가 제어에 영향을 줄
흐름.

@joshtriplett 나는 표준 의미에서 제어 흐름에 영향을 미치지 않습니다. 이것은 차입 검사기가 정의 된대로 미래에서 작동해야한다는 것을 정당화하기위한 기본 사실입니다 (핀은 방법을 추론

문법 토론과 상충됩니다. 그리고 문제는 단지 지금이 아니라 5 년, 10 년, 20 년 후, 몇 번의 에디션을 거쳐야합니다.

이게 무슨 뜻인지 모르겠습니다.

나는 이미 문법에 의해 완전히 지원되기 때문에 명예가 await!(future) 있다고 생각합니다.

이해 합니다만,이 시점에서이 구문이 가지고있는 다른 많은 단점으로 인해 효과적으로 배제되었다고 생각합니다.

@Centril try! 은 ? 연산자가 더 많은 작업을 수행 할 수 있기 때문에 결국 중복되었습니다. "언어에 부적합"하지 않습니다. 하지만 당신은 그것을 _ 좋아하지 않을 수도 있습니다.

Rust 2018에서 try!(expr) 를 작성하는 것은 명시 적으로 폐기되었으며 더 나아가 어려운 오류입니다. 우리는 집합 적으로 그렇게하기로 결정했고 따라서 부적합한 것으로 간주되었습니다.

.await!() 를 사용하는 주된 이유는 매크로처럼 보이기 때문에 제어 흐름에 영향을 줄 수 있다는 것을 분명히하기 때문입니다.

.await 는 필드 액세스처럼 보이고 .await() 는 함수 호출처럼 보이며 필드 액세스 나 함수 호출 모두 제어 흐름에 영향을 줄 수 없습니다.

나는 구별 특히, 어떤 사용자가 비교적 쉽게 배울 것이라고 생각 .await 일반적으로 다음됩니다 ? (기능 로컬 제어 흐름이다). 함수 호출에 관해서는 앞서 언급했듯이 반복기 메서드가 제어 흐름의 한 형태라고 말하는 것이 타당하다고 생각합니다. 더욱이, 매크로 가 제어 흐름에 영향을 미칠 것이라는 의미는 아닙니다. 많은 매크로는 그렇지 않습니다 (예 : dbg! , format! , ...). .await!() 또는 .await 가 제어 흐름에 영향을 미칠 것이라는 이해 ( @HeroicKatora 의 메모에 따라 ? 보다 훨씬 약한 의미에서)는 await 라는 단어에서 유래합니다.

센트릴

이것은 현재의 실제 키워드가 아닌 문맥 키워드를 기다리는 것을 수반합니다. 그렇게해서는 안된다고 생각합니다.

Eek. 약간 고통 스럽습니다. 아마도 매크로는 .wait!() 또는 .awaited!() 와 같은 다른 이름을 가질 수 있습니다 (후자는 앞의 표현식에 적용된다는 것을 분명히하기 때문에 꽤 좋습니다).

"그렇다면 컴파일러 마법없이 .await! () 접미사를 구현할 수 있습니다."
이것은 foo await 또는 foo.await (특히 후자)보다 구현 측면에서 더 복잡한 솔루션입니다. 그것과 마찬가지로 여전히 "마법"이 있습니다. 방금 회계 책정을 마쳤습니다.

또한 컴파일러의 지원없이 try! (..)가 정의됩니다.

접두사 await 키워드와 접미사 매크로가 있으면 컴파일러 지원없이 .await!() (다른 이름으로)도 구현할 수 있습니다. 물론 await 키워드 자체는 여전히 상당한 양의 컴파일러 마법을 수반하지만 이는 단순히 매크로의 결과에 적용되며 try!() 의 관계와 다르지 않습니다. return 키워드.

나중에 .await! ()를 추가 할 경우 사용자에게 더 많은 정보를 제공 할뿐 (await foo 및 foo.await! ()) 이제 사용자는 "언제 사용해야하는지 .."라고 묻습니다. 이것은 단일 솔루션처럼 foo await 또는 foo.await보다 복잡성 예산을 더 많이 사용하는 것 같습니다.

이로 인해 사용자에게 추가되는 복잡성은 최소한이라고 생각합니다 (구현 복잡성은 다른 문제 일 수 있지만 어쨌든 접미사 매크로를 원한다면 ...). 두 형식 모두 직관적으로 읽으므로 둘 중 하나를 읽을 때 무슨 일이 일어나고 있는지 분명해야합니다. 코드를 작성할 때 선택할 수있는 문서는 다음과 같이 간단하게 말할 수 있습니다.

"Rust에서 Future를 기다리는 방법은 두 가지가 있습니다 : await foo.bar(); 및 foo.bar().await!() .이 방법은 스타일 선호이며 실행 흐름에 차이가 없습니다."

나는 "개방 된 가능성을 남겨두기"에 가치가 없다고 본다. 구성, IDE 경험 등에 대한 접미사의 가치는 오늘날 알려져 있습니다.

사실입니다. 나는 우리의 구현이 미래에 더 통일 된 언어를 가질 가능성을 막지 않도록하는 것이 더 중요하다고 생각합니다.

이게 무슨 뜻인지 모르겠습니다.

별로 중요하지 않습니다. 그러나 일반적으로 구문이 잘 강조 표시되지 않고 분명 할 때도 선호합니다. 따라서 git diff 및 기타 이러한 컨텍스트에서 두드러집니다.

이론적으로 예, 사소한 프로그램의 경우 예,하지만 실제로는 프로그래머
정지 지점이 어디에 있는지 알아야합니다.

간단한 예를 들어, 일시 중단 지점에서 RefCell을 유지하고
프로그램의 동작은 RefCell이
일시 중단 지점 전에 해제됩니다. 대규모 프로그램에는
이와 같은 수많은 미묘함, 현재 기능이
중단은 중요한 정보입니다.

2019 년 1 월 23 일 수요일 오후 2:21 HeroicKatora [email protected]
썼다 :

@joshtriplett https://github.com/joshtriplett 나는 제어에 영향을 미치지 않습니다
표준적인 의미의 흐름. 이것이 정당화하는 기본적인 사실입니다.
차입 검사기는 정의 된대로 미래에서 작동해야합니다. 보기에서
로컬 함수 실행, await 실행은 다른 함수 호출과 같습니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/57640#issuecomment-456989262 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABGmeqcr2g4olxQhH9Fb9r6g3XRaFUu2ks5vGOBkgaJpZM4aBlba
.

Wed, Jan 23, 2019 at 02:26:07 PM -0800, Mazdak Farrokhzad write :

.await!() 를 사용하는 주된 이유는 매크로처럼 보이기 때문에 제어 흐름에 영향을 줄 수 있다는 것을 분명히하기 때문입니다.

.await 는 필드 액세스처럼 보이고 .await() 는 함수 호출처럼 보이며 필드 액세스 나 함수 호출 모두 제어 흐름에 영향을 줄 수 없습니다.

구분은 사용자가 비교적 쉽게 배울 수있는 부분이라고 생각합니다.

왜 그래야합니까?

나는 구별이 사용자가 비교적 쉽게 배울 수 있다고 생각합니다. 특히 .await 뒤에는? (기능-로컬 제어 흐름).

종종 그렇지만 항상 그런 것은 아니며 구문은 그렇지 않은 경우에 확실히 작동해야합니다.

함수 호출에 관해서는 앞서 언급했듯이 반복기 메서드가 제어 흐름의 한 형태라고 말하는 것이 타당하다고 생각합니다.

return 또는 ? (또는 break )와 같은 방식이 아닙니다. 함수 호출이 호출 한 함수에서 두 단계를 반환하거나 (Rust에 예외가없는 이유 중 하나는 이것이 놀랍기 때문입니다) 호출에서 루프에서 벗어날 수 있다면 매우 놀랍습니다. 함수.

더욱이 매크로가 제어 흐름에 영향을 미칠 수 있다고해서 그렇게 할 것이라는 의미는 아닙니다. 많은 매크로는 그렇지 않습니다 (예 : dbg !, format !, ...). 이해 .await 그! () 또는 .await 단어 자체를 기다리고 흐름 (?, 당 @HeroicKatora의 노트보다 훨씬 약한 의미에서 THO) 제어 흐름에 영향을 미칠 것입니다.

나는 이것을 전혀 좋아하지 않는다. 제어 흐름에 영향을주는 것은 정말 중요한 부작용입니다. 일반적으로 이것을 할 수없는 구조와 다른 구문 형식을 가져야합니다. Rust에서이를 수행 할 수있는 구성은 키워드 ( return , break , continue ), 연산자 ( ? ), 매크로 (하나로 평가하여 다른 형태의). 예외를 추가하여 물을 진흙으로 만드는 이유는 무엇입니까?

@ejmahler 일반 함수 호출과의 비교를 위해 RefCell을 보유하는 것이 어떻게 다른지 알 수 없습니다. 내부 함수가 동일한 RefCell을 획득하려고 할 수도 있습니다. 그러나 모든 잠재 콜 그래프를 즉시 파악하지 못하는 문제는 아무도없는 것 같습니다. 마찬가지로 스택 고갈 문제는 제공된 스택 공간에 주석을 추가해야한다는 특별한 우려가 없습니다. 여기서 비교는 코 루틴에 유리할 것입니다! 인라인되지 않은 일반 함수 호출을 더 잘 보이게해야합니까? 점점 더 어려워지는 라이브러리 문제를 파악하기 위해 명시적인 테일 호출이 필요합니까?

대답은 imho입니다. RefCell을 사용할 때 가장 큰 위험은 익숙하지 않다는 것입니다. 위의 다른 문제가 하드웨어에서 추상화 될 수있을 때, 저는 프로그래머로서 우리가 조사한 곳을 제외하고 수율 지점에서 RefCell 등을 붙 잡지 않는 방법을 배울 수 있다고 생각합니다.

2019 년 1 월 23 일 수요일 10:30:10 PM +0000에 Elliott Mahler는 다음과 같이 썼습니다.

이론적으로 예, 사소한 프로그램의 경우 예,하지만 실제로는 프로그래머
정지 지점이 어디에 있는지 알아야합니다.

: +1 :

안녕하세요.

중요한 차이점은 검사해야하는 코드의 양,
설명해야 할 가능성. 프로그래머는 이미
그들이 호출하는 것은 그들이 확인한 RefCell을 사용하는지 확인
밖. 그러나 await를 사용하면 단일 호출 스택을 검사하는 대신
await 동안 실행되는 내용을 제어 할 수 있습니다.
프로그램이 실행될 수 있습니다. 내 직감에 따르면 평균적인 프로그래머는
이러한 가능성의 폭발을 처리 할 수있는 장비가 훨씬 적습니다.
훨씬 덜 자주 처리해야합니다.

정지 지점이 중요한 정보 인 또 다른 예는 게임에서
일반적으로 재개 될 코 루틴을 작성합니다.
프레임 당 한 번씩 이력서마다 게임 상태를 변경합니다. 우리가 간과한다면
이 코 루틴 중 하나에서 일시 중지 지점을 유지하면 게임을 중단 된 상태로 둘 수 있습니다.
여러 프레임에 대한 상태.

이 모든 것들은“더 똑똑해지고
물론, 그 접근 방식은 역사적으로 효과가 없습니다.

2019 년 1 월 23 일 수요일 오후 2:44 Josh Triplett [email protected]
썼다 :

2019 년 1 월 23 일 수요일 10:30:10 PM +0000에 Elliott Mahler는 다음과 같이 썼습니다.

이론적으로 예, 사소한 프로그램의 경우 예,하지만 실제로는 프로그래머
정지 지점이 어디에 있는지 알아야합니다.

: +1 :

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/57640#issuecomment-456995913 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABGmep05nhZizdE5xil4FsnpONJCxqn-ks5vGOXhgaJpZM4aBlba
.

정지 지점이 중요한 정보 인 또 다른 예를 들어, 게임 프로그래밍에서 일반적으로 프레임 당 한 번 재개되도록 의도 된 코 루틴을 작성하고 각 이력서에서 게임 상태를 변경합니다. 이러한 코 루틴 중 하나에서 일시 중단 지점을 간과하면 여러 프레임 동안 게임이 중단 된 상태로 남을 수 있습니다.

SlotMap에 키를 놓으면 메모리가 누출됩니다. 언어 자체는 본질적으로 이것에 도움이되지 않습니다. 내가 말하고 싶은 것은 await가 어떻게 모호하게 보이지 않는지 (키워드 인 한 그 발생이 고유 한 경우) 다른 기능에 대해 발생하지 않은 문제로 일반화되지 않는 것입니다. 나는 당신이 언어가 당신에게 즉시 어떤 기능을 제공하는지에 대한 평가를 줄이고 당신이 자신의 특성을 표현할 수있게하는 방법에 대해 더 많이 평가해야한다고 생각합니다. 도구를 평가 한 다음 적용하십시오. 게임 상태에 대한 솔루션 제안 및이 문제를 충분히 해결하는 방법 : 게임 상태가 실제로 필요한 양을 틱했다는 반환시 주장하는 래퍼를 작성하면 비동기를 통해 해당 원인에 대한 자체 상태를 빌릴 수 있습니다. 그 구획화 된 코드에서 다른 금지가 기다리고 있습니다.

RefCell의 상태 폭발은 다른 곳에서 사용되지 않는지 확인하지 않고 해당 불변에 의존하고 조용히 추가하는 다른 코드 포인트에서 발생합니다. 이것들은 같은 방식으로, 문서화, 주석, 올바른 포장으로 처리됩니다.

RefCell 보유하는 것은 차단 io를 수행 할 때 Mutex 를 보유하는 것과 크게 다르지 않습니다. 교착 상태가 발생할 수 있으며, 이는 패닉보다 더 나쁘고 디버깅하기 어렵습니다. 그러나 우리는 명시적인 block 키워드로 차단 작업에 주석을 달지 않습니다. :).

비동기 함수간에 RefCell 공유하면 일반적인 사용성 ( !Send )이 크게 제한되므로 일반적이지 않을 것이라고 생각합니다. 그리고 RefCell 는 일반적으로 피해야하며 사용시 가능한 한 짧은 시간 동안 빌려야합니다.

그래서 저는 수익률 포인트에 우연히 RefCell 집어 넣는 것이 큰 문제라고 생각하지 않습니다.

이러한 코 루틴 중 하나에서 일시 중단 지점을 간과하면 여러 프레임 동안 게임이 중단 된 상태로 남을 수 있습니다.

코 루틴과 비동기 함수는 다릅니다. yield 암시 적으로 만들려는 것이 아닙니다.

여기에 키워드 구문 대신 매크로 구문을 선호하는 사람에게 : await 에 대해 설명해주세요. 즉, 매크로 여야한다는 의미와 while 와는 어떻게 다른지 설명해주세요. while! 매크로 macro_rules! 만 사용하더라도 특수 대소 문자는 아예 없음).

편집 : 이것은 수사적이지 않습니다. 나는 C #과 같은 run-to-first-await를 원한다고 생각한 것과 같은 방식으로 진정으로 관심이 있지만 RFC는 그렇지 않다고 확신했습니다.

여기에 키워드 구문 대신 매크로 구문을 선호하는 사람에게 : await가 무엇인지 설명해주세요. 즉, 매크로 여야한다는 의미이며, 잠시만 기다려야하는 while과 어떻게 다른지 설명해주세요! 매크로 (macro_rules 만 사용하더라도!; 특수 대소 문자는 전혀 없음).

나는 대부분이 추론에 동의하며 접두사 구문에 키워드를 사용하고 싶습니다.

그러나, (https://github.com/rust-lang/rust/issues/57640#issuecomment-456990831) 위에서 설명한대로, 나는 또한 접미사 구문 (아마도에 대한 후위 매크로를 가지고 찬성 해요 .awaited!() 접두사 키워드와 이름 충돌을 피하기 위해

• foo.bar().await 및 foo.bar().await() 은 기술적으로 키워드이지만 필드 액세스 또는 메서드 호출처럼 보이며 이러한 제어 흐름 수정 구조가 이렇게 숨겨져 있어야한다고 생각하지 않습니다.
• foo.bar() await 는 특히 foo.bar() await.qux() 와 같은 추가 연결에서 혼란 스럽습니다. 나는 그런 접미사로 사용되는 키워드를 본 적이 없습니다 (그들이 존재한다고 확신하지만 실제로 이와 같이 작동하는 키워드에 대해 알고있는 어떤 언어로도 단일 예제를 생각할 수 없습니다). 그리고 나는 await를가에 적용되는 경우로는 매우 혼동을 읽고 생각 qux() 하지 foo.bar() .
• foo.bar()@await 또는 다른 구두점을 사용할 수 있습니다. 그러나 그것은 특히 좋지 않으며 꽤 임시적인 느낌입니다. 실제로 위의 옵션과 달리이 구문에 중요한 문제가 없다고 생각합니다. 시길을 추가하기 시작하면 균형이 맞춤 구문을 버리고 매크로가되는쪽으로 기울이기 시작하는 것 같습니다.

새로운 생각과 고려 사항을 수정했지만 이전 아이디어를 다시 한 번 반복 한 다음 침묵을 유지하려고합니다.

await 키워드는 async 함수 내에서만 유효하므로 다른 곳에서 await 식별자를 허용해야합니다. 외부 범위에서 변수 이름이 await 이면 원시 식별자로 사용되지 않는 한 async 블록 내에서 액세스 할 수 없습니다. 또는 예를 들어 await! 매크로가 있습니다.

또한, 키워드를 그렇게 조정하면 내 요점을 얻을 수 있습니다. 다음과 같이 생성기와 비동기 함수의 혼합 및 일치를 허용해야합니다.

// 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);
}

나는 이것이 펑키 한 일을하고 싶어하는 초 고급 사용자에게는 충분히 투명하다고 생각하지만, 신규 및 중급 사용자는 필요한 것만 사용할 수 있습니다. yield 문없이 사용하는 경우 2와 3은 사실상 동일합니다.

나는 또한 접두사 await? 가 비동기 작업의 결과에 ? 를 추가하는 훌륭한 축약이라고 생각하지만 반드시 필요한 것은 아닙니다.

접미사 매크로가 공식적인 것이된다면 (내가 원하는대로) await!(...) 및 .await!() 둘 다 함께 존재할 수 있으며, 특정 사용 사례 및 스타일에 대해 세 가지 동등한 방법을 사용할 수 있습니다. . 나는 이것이인지 오버 헤드를 추가 할 것이라고 생각하지 않지만 더 큰 유연성을 허용 할 것입니다.

이상적으로 async fn 및 #[async] fn* 는 기본 생성기를 비동기 상태 머신으로 변환하기위한 구현 코드를 공유 할 수도 있습니다.

이러한 문제로 인해 진정한 선호하는 스타일이 없다는 것이 분명해 졌으므로 내가 바라는 최선의 방법은 깨끗하고 유연하며 읽기 쉽고 접근하기 쉬운 복잡성 수준을 제공하는 것입니다. 위의 계획은 미래를위한 좋은 타협이라고 생각합니다.

키워드로 await 은 어쨌든 async 함수 내에서만 유효하므로 식별자가 다른 곳에서 대기하도록 허용해야합니다.

위생적인 매크로를 고려할 때 이것이 Rust에서 실용적인지 모르겠습니다. expr 원할 때 foo!(x.await) 또는 foo!(await { x }) 호출하면 expr 가 아닌 await 키워드를 원한다는 것이 분명해야한다고 생각합니다 await 필드 또는 필드 init 속기의 await 구조체 리터럴 표현식-동기 메서드에서도 마찬가지입니다.

세 가지 동등한 방법이 기다립니다.

제발 안돼. (적어도 core . 분명히 사람들은 자신의 코드로 매크로를 만들 수 있습니다. 원한다면)

지금은 접미사 .await! () 매크로에는 컴파일러 마법이 필요합니다. 그러나 await 키워드의 접두사 변형이 안정화되면 더 이상 사실이 아닙니다. postfix .await! () 매크로는 인수 (표현식) 앞에 await 키워드를 붙이고 래핑 된 매크로로 간단하게 구현 될 수 있습니다. 괄호 안의 모든 것.

나는 이것이 똑같이 사실이지만 더 쉽다는 것을 주목할 것입니다! -다른 방향으로 : .await 키워드 구문을 안정화하면 사람들이 접미사를 충분히 싫어한다면 이미 awaited!() 접두사 매크로를 만들 수 있습니다.

여러 허용 된 변형 (예 : 접두사 및 접미사)을 추가하는 아이디어는 싫지만 사용자가 묻는 것과는 약간 다른 이유 때문입니다. 나는 다소 큰 회사에서 일하고 있으며 코드 스타일을 놓고 싸우는 것은 진짜입니다. 명확하고 올바른 형식을 하나만 사용하고 싶습니다. 결국, 파이썬의 선은이 점과 관련하여 옳을 수 있습니다.

여러 허용 된 변형 (예 : 접두사 및 접미사)을 추가하는 아이디어는 싫지만 사용자가 묻는 것과는 약간 다른 이유 때문입니다. 나는 다소 큰 회사에서 일하고 있으며 코드 스타일을 놓고 싸우는 것은 진짜입니다. 명확하고 올바른 형식을 하나만 사용하고 싶습니다. 결국, 파이썬의 선은이 점과 관련하여 옳을 수 있습니다.

무슨 말인지 알아요. 그러나 프로그래머가 await!() 와 같은 작업을 수행하는 자체 매크로를 정의하는 것을 막을 방법은 없습니다. Simular 구조체는 항상 가능합니다. 그래서 실제로는 어쨌든 다른 변형이있을 것입니다.

글쎄, 적어도 await!(...) 은 (는) 오류가 될 것이기 때문에; 그러나 사용자가 macro_rules! wait { ($e:expr) => { e.await }; } 정의한 다음 wait!(expr) 로 사용하면 명백하게 일관 적으로 보이고 유행에서 벗어나기 쉽습니다. 이는 생태계의 변화 가능성을 크게 줄이고 사용자가 스타일을 덜 배울 수 있도록합니다. 따라서 @yasammez 의 요점이 적절하다고 생각합니다.

@Centril 누군가 나쁜 일을하고 싶다면 거의 멈출 수 없습니다. _await!() 또는 awai!() 어떻습니까?

또는 유니 코드 식별자가 활성화 된 경우 àwait!() 와 같은 것입니다.

...

@earthengine 목표는 다양한 사람들이 의도적으로 이상한 일을하는 것을 막는 것이 아니라 (스타일 린트와 rustfmt 로하는 것과 비슷한) 커뮤니티 규범 을 설정하는 것입니다. 여기서는 _await!() 가) 보이지 않는다는 절대적인 보장이 아니라 확률을 다루고 있습니다.

각 접미사 구문에 대한 인수를 요약하고 검토해 보겠습니다.

• __ expr await (접미사 키워드) __ : Postfix 키워드 구문은 이미 예약 한 await 키워드를 사용합니다. Await는 마법의 변형이며 키워드를 사용하면 적절하게 눈에 띄는 데 도움이됩니다. 필드 액세스, 메서드 또는 매크로 호출처럼 보이지 않으며 예외로 설명 할 필요가 없습니다. 현재 구문 분석 규칙 및 ? 연산자와 잘 맞습니다. 메서드 체이닝의 공간은 어떤 형태로든 받아 들여질 가능성이있는 RFC 인 Generalized Type Ascription 보다 나쁘지 않습니다 . 단점은 IDE가 await 대한 자동 완성을 제공하기 위해 더 많은 마술을해야 할 수도 있다는 것입니다. 사람들은 메소드 체인의 공간이 너무 귀찮다고 생각할 수 있습니다 ( 있다고 주장 했지만), 특히 await 가 각 줄을 끝내도록 형식이 지정되지 않은 경우 특히 그렇습니다. 다른 접근 방식을 취하면 사용을 피할 수있는 키워드를 사용합니다.

• __ expr.await (접미사 필드) __ : 접미사 필드 구문은 "점의 힘"을 활용합니다. 연결이 자연스럽게 보이고 IDE가 다른 작업을 수행하지 않고도 await 를 자동 완성 할 수 있습니다 (예 : 점 을

• __ expr.await() (접미사 방법) __ : 접미사 방법 구문은 접미사 필드와 유사합니다. 장점은 () 호출 구문이 독자에게 "이것은 무언가를합니다."라는 것을 나타냅니다. 로컬에서 보면 블로킹 메서드에 대한 호출이 다중 스레드 프로그램에서 실행되는 것과 같은 방식으로 거의 의미 가 있습니다. 단점은 조금 더 길고 시끄럽고 await 의 마법 행동을 메서드로 위장하면 혼란 스러울 수 있습니다. await 는 Scheme의 call/cc 가 함수 인 것과 동일한 제한적 의미의 메서드라고 말할 수 있습니다. 한 가지 방법으로 Future::await(expr) 가 UFCS 와 일관되게 작동하는지 여부를 고려해야합니다.

• __ expr.await!() (접미사 매크로) __ : Postfix 매크로 구문은 유사하게 "점의 힘"을 활용합니다 ! bang 매크로는 "이것은 마술을 할 수 있습니다"를 나타냅니다. 단점은 훨씬 더 시끄럽고 매크로가 마법을 수행하지만 일반적으로 await 처럼 주변 코드에 마법을 적용하지 않습니다. 또한 단점은 범용 접미사 매크로 구문을 표준화한다고 가정하면 await 를 키워드로 계속 처리하는 데 문제 가있을 수 있습니다.

• __ expr@ , expr# , expr~ 및 기타 단일 문자 기호 __ : ? 와 같이 단일 문자를 사용하면 간결성을 최대화하고 접미사 구문을 만들 수 있습니다. 더 자연스럽게 보입니다. ? 와 마찬가지로 await 이 코드에 스며 들기 시작하면이 간결함에 감사 할 것입니다. 단점은 코드를 await 흩 뿌려 놓는 고통이 문제가되지 않는 한 그러한 구문을 채택하는 데 내재 된 트레이드 오프에 대한 합의를보기가 어렵습니다.