Rust: async/await에 대한 추적 문제(RFC 2394)

여기에서 논의가 끝난 것 같으므로 여기에 await 구문 질문의 일부로 연결합니다. https://internals.rust-lang.org/t/explicit-future-construction-implicit-await/ 7344

구현이 #50307에서 차단되었습니다.

구문 정보: await 를 단순 키워드로 사용하고 싶습니다. 예를 들어 블로그의 우려 사항을 살펴보겠습니다.

우리는 await 키워드에 대해 원하는 구문이 무엇인지 정확히 확신하지 못합니다. 어떤 것이 결과의 미래인 경우 - 모든 IO 미래가 그럴 가능성이 있는 경우 - 당신은 그것을 기다리고 ? 연산자를 그것에 적용할 수 있기를 원합니다. 그러나 이를 가능하게 하는 우선 순위는 놀라운 것처럼 보일 수 있습니다. ? 가 await보다 어휘적으로 더 밀접하게 연결되어 있음에도 불구하고 await io_future? 는 첫 번째로 await 이고 ? 두 번째입니다.

나는 여기에 동의하지만 중괄호는 나쁘다. ? 가 await 보다 우선 순위가 낮다는 것을 기억하고 다음과 같이 끝내는 것이 더 쉽다고 생각합니다.

let foo = await future?

읽기가 더 쉽고 리팩토링이 더 쉽습니다. 나는 그것이 더 나은 접근 방식이라고 믿습니다.

let foo = await!(future)?

작업이 실행되는 순서를 더 잘 이해할 수 있지만 가독성이 떨어집니다.

await foo? await 먼저 실행하면 문제가 없다고 생각합니다. 아마도 어휘적으로 더 묶여 있지만 await 는 왼쪽에 있고 ? 는 오른쪽에 있습니다. 따라서 await 먼저 Result 를 처리하고 그 뒤에

의견 불일치가 있는 경우 이를 표현하여 논의할 수 있도록 하십시오. 나는 조용한 downvote가 무엇을 의미하는지 이해하지 못합니다. 우리 모두는 러스트에게 행운이 있기를 바랍니다.

await 가 @Pzixel이라는 키워드에 대해 혼합된 견해가 있습니다. 확실히 미학적 매력이 있고 더 일관성이 있지만 async 가 키워드라는 점을 감안할 때 모든 언어에서 "키워드 팽창"은 실제 문제입니다. 즉, async 없이 await 를 사용하는 것이 기능적으로는 의미가 있습니까? 그렇다면 그대로 둘 수 있습니다. 그렇지 않다면 await 키워드를 만드는 쪽으로 기울고 싶습니다.

? 가 await 보다 우선순위가 낮다는 것을 기억하고 그것으로 끝내는 것이 더 쉽다고 생각합니다.

그걸 배워서 내면화할 수도 있겠지만, 만지는 것들이 공백으로 구분된 것보다 더 촘촘하게 묶인다는 강한 직관력이 있어서 실전에서는 항상 언뜻 틀리게 읽힐 것 같아요.

또한 모든 경우에 도움이 되지는 않습니다. 예를 들어 Result<impl Future, _> 를 반환하는 함수는 다음과 같습니다.

let foo = await (foo()?)?;

여기서 관심은 단순히 "단일 await+ ? 의 우선 순위를 이해할 수 있습니까?"뿐만 아니라 "여러 await를 연결하는 것이 어떻게 생겼는지"입니다. 따라서 우선 순위를 선택하더라도 여전히 await (await (await first()?).second()?).third()? 문제가 있습니다.

await 구문에 대한 옵션 요약, 일부 는 RFC 에서, 나머지는 RFC 스레드에서:

• 어떤 종류의 구분 기호가 필요합니다: await { future }? 또는 await(future)? (이것은 시끄럽습니다).
• await future? 또는 (await future)? 가 예상대로 작동하도록 우선 순위를 선택하기만 하면 됩니다(둘 다 놀랍습니다).
• 두 연산자를 await? future 와 같은 것으로 결합합니다(이것은 드문 일입니다).
• future await? 또는 future.await? 와 같이 어떻게든 await 접미사를 만듭니다(이것은 전례가 없는 일입니다).
• future@? 에서와 같이 ? 와 같은 새 인장을 사용하십시오(이것은 "라인 노이즈"입니다).
• 구문을 전혀 사용하지 않고 await를 암시적으로 만듭니다(이는 일시 중단 지점을 더 보기 어렵게 만듭니다). 이것이 작동하려면 미래를 구성하는 행위도 명시되어야 합니다. 이것은 위에서 링크한 내부 스레드 의 주제입니다.

즉 가진 않습니다 말했다 async 하지 않고 await 도 지혜, 기능을 이해가?

@alexreg 그렇습니다 . 예를 들어 Kotlin은 이런 식으로 작동합니다. 이것은 "암시적 대기" 옵션입니다.

@rpjohnst 흥미 async 및 await 를 언어의 명시적 기능으로 남겨두는 것에 찬성합니다. 왜냐하면 이것이 Rust의 정신에 더 가깝다고 생각하기 때문입니다. 그러나 비동기 프로그래밍에 대한 전문가는 아닙니다. ..

@alexreg async/await는 C#(내 기본 언어)에서 일상적으로 작업하기 때문에 정말 좋은 기능입니다. @rpjohnst 는 모든 가능성을 매우 잘 분류했습니다. 나는 두 번째 옵션을 선호하며 다른 고려 사항(시끄러운/비정상적/...)에 동의합니다. 저는 지난 5년 동안 비동기/대기 코드로 작업해 왔습니다. 이러한 플래그 키워드를 갖는 것이 정말 중요합니다.

@rpjohnst

따라서 우선 순위를 선택하더라도 여전히 await (await (await first()?).second()?).third()? 문제가 있습니다.

내 연습에서는 한 줄에 두 개의 await 를 쓰지 않습니다. 매우 드물게 필요할 때 then 로 다시 작성하고 await를 전혀 사용하지 마십시오. 읽기가 훨씬 어렵다는 것을 스스로 알 수 있습니다.

let first = await first()?;
let second = await first.second()?;
let third = await second.third()?;

따라서 기본 사례를 더 간단하고 더 좋게 만들기 위해 언어가 그러한 방식으로 코드를 작성하는 것을 권장하지 않더라도 괜찮다고 생각합니다.

히어로 어웨이 future await? 낯설지만 흥미롭게 보이지만 이에 대한 논리적 반론은 보이지 않습니다.

내 연습에서는 한 줄에 두 개의 await 를 쓰지 않습니다.

그러나 이것은 구문에 관계없이 나쁜 생각이기 때문입니까, 아니면 C#의 기존 await 구문이 보기 흉하기 때문입니까? 사람들은 try!() ( ? 의 전신)에 대해 비슷한 주장을 했습니다.

접미사 및 암시적 버전은 훨씬 덜 추합니다.

first().await?.second().await?.third().await?

first()?.second()?.third()?

그러나 이것은 구문에 관계없이 나쁜 생각이기 때문입니까, 아니면 C#의 기존 await 구문이 보기 흉하기 때문입니까?

async 연산당 한 줄을 갖는 것은 이미 이해하기에 충분히 복잡하고 디버그하기 어렵기 때문에 구문에 관계없이 나쁜 생각이라고 생각합니다. 그것들을 하나의 문장으로 묶는 것은 훨씬 더 나쁜 것 같습니다.

예를 들어 실제 코드를 살펴보겠습니다(저는 프로젝트에서 한 부분을 가져왔습니다).

[Fact]
public async Task Should_UpdateTrackableStatus()
{
    var web3 = TestHelper.GetWeb3();
    var factory = await SeasonFactory.DeployAsync(web3);
    var season = await factory.CreateSeasonAsync(DateTimeOffset.UtcNow, DateTimeOffset.UtcNow.AddDays(1));
    var request = await season.GetOrCreateRequestAsync("123");

    var trackableStatus = new StatusUpdate(DateTimeOffset.UtcNow, Request.TrackableStatuses.First(), "Trackable status");
    var nonTrackableStatus = new StatusUpdate(DateTimeOffset.UtcNow, 0, "Nontrackable status");

    await request.UpdateStatusAsync(trackableStatus);
    await request.UpdateStatusAsync(nonTrackableStatus);

    var statuses = await request.GetStatusesAsync();

    Assert.Single(statuses);
    Assert.Equal(trackableStatus, statuses.Single());
}

실제로는 구문이 허용하더라도 await 를 연결할 가치가 없음을 보여줍니다. await 는 완전히 읽을 수 없게 되기 때문입니다. 그것이 나쁜 유일한 이유는 아니라고 믿습니다.

접미사 및 암시적 버전은 훨씬 덜 추합니다.

작업 시작과 작업 대기를 구별하는 가능성은 정말 중요합니다. 예를 들어, 나는 종종 다음과 같은 코드를 작성합니다(다시, 프로젝트의 스니펫).

public async Task<StatusUpdate[]> GetStatusesAsync()
{
    int statusUpdatesCount = await Contract.GetFunction("getStatusUpdatesCount").CallAsync<int>();
    var getStatusUpdate = Contract.GetFunction("getStatusUpdate");
    var tasks = Enumerable.Range(0, statusUpdatesCount).Select(async i =>
    {
        var statusUpdate = await getStatusUpdate.CallDeserializingToObjectAsync<StatusUpdateStruct>(i);
        return new StatusUpdate(XDateTime.UtcOffsetFromTicks(statusUpdate.UpdateDate), statusUpdate.StatusCode, statusUpdate.Note);
    });

    return await Task.WhenAll(tasks);
}

여기에서 N개의 비동기 요청을 생성한 다음 이를 기다리고 있습니다. 우리는 각 루프 반복을 기다리지 않지만 먼저 비동기 요청 배열을 만든 다음 한 번에 모두 기다립니다.

나는 Kotlin을 모르기 때문에 어떻게 든 이것을 해결할 수 있습니다. 하지만 작업을 "실행 중"과 "대기 중"이 동일한 경우 어떻게 표현할 수 있는지 모르겠습니다.

따라서 암시적 버전은 C#과 같은 훨씬 더 암시적인 언어에서는 불가능하다고 생각합니다.
u8 를 i32 로 암시적으로 변환하는 것조차 허용하지 않는 규칙이 있는 Rust에서는 훨씬 더 혼란스러울 것입니다.

@Pzixel 예, 두 번째 옵션이 더 선호되는 옵션 중 하나인 것 같습니다. C#에서도 async/await 를 사용해 보았지만 몇 년 동안 주로 C#으로 프로그래밍하지 않았기 때문에 그다지 많이 사용하지는 않았습니다. 우선 순위는 await (future?) 가 더 자연스럽습니다.

@rpjohnst 저는 후위 연산자라는 개념이 마음에 struct 라는 await 의 구성원에게는 쉽게 혼동될 수 있습니다. .

작업 시작과 작업 대기를 구별하는 가능성은 정말 중요합니다.

그만한 가치가 있기 때문에 암시적 버전 이 이 작업을 수행합니다. RFC 스레드와 내부 스레드 모두에서 죽을 정도로 논의되었으므로 여기서 자세히 설명하지 않겠지만 기본 아이디어는 명시성을 작업 대기에서 작업 구성으로 이동 한다는 것뿐입니다. 새로운 암시를 도입하지 마십시오.

귀하의 예는 다음과 같습니다.

pub async fn get_statuses() -> Vec<StatusUpdate> {
    // get_status_updates is also an `async fn`, but calling it works just like any other call:
    let count = get_status_updates();

    let mut tasks = vec![];
    for i in 0..count {
        // Here is where task *construction* becomes explicit, as an async block:
        task.push(async {
            // Again, simply *calling* get_status_update looks just like a sync call:
            let status_update: StatusUpdateStruct = get_status_update(i).deserialize();
            StatusUpdate::new(utc_from_ticks(status_update.update_date), status_update.status_code, status_update.note))
        });
    }

    // And finally, launching the explicitly-constructed futures is also explicit, while awaiting the result is implicit:
    join_all(&tasks[..])
}

이것이 내가 "이것이 작동하려면 미래를 건설하는 행위도 명시되어야 한다"는 의미입니다. 동기화 코드에서 스레드로 작업하는 것과 매우 유사합니다. 함수 호출은 호출자를 다시 시작하기 전에 항상 완료될 때까지 기다리며 동시성을 도입하기 위한 별도의 도구가 있습니다. 예를 들어, 클로저 및 thread::spawn / join 는 비동기 블록 및 join_all / select /etc에 해당합니다.

그만한 가치가 있기 때문에 암시적 버전이 이 작업을 수행합니다. RFC 스레드와 내부 스레드 모두에서 죽을 정도로 논의되었으므로 여기서 자세히 설명하지 않겠지만 기본 아이디어는 명시성을 작업 대기에서 작업 구성으로 이동한다는 것뿐입니다. 새로운 암시를 도입하지 마십시오.

나는 그것을 믿는다. 여기에서 이 함수의 흐름이 무엇인지 알 수 없습니다. 여기서 는 대기가 완료될 때까지 실행이 중단되는 지점입니다. async 블록만 볼 수 있습니다. "안녕하세요, 여기 어딘가에 비동기 기능이 있습니다. 어떤 기능이 있는지 찾아보세요. 놀랄 것입니다!"

또 다른 요점: Rust는 베어메탈 등에 가까운 모든 것을 표현할 수 있는 언어인 경향이 있습니다. 상당히 인공적인 코드를 제공하고 싶지만 다음과 같은 아이디어를 보여 주는 것 같습니다.

var a = await fooAsync(); // awaiting first task
var b = barAsync(); //running second task
var c = await bazAsync(); // awaiting third task
if (c.IsSomeCondition && !b.Status = TaskStatus.RanToCompletion) // if some condition is true and b is still running
{
   var firstFinishedTask = await Task.Any(b, Task.Delay(5000)); // waiting for 5 more seconds;
   if (firstFinishedTask != b) // our task is timeouted
      throw new Exception(); // doing something
   // more logic here
}
else
{
   // more logic here
}

Rust는 항상 무슨 일이 일어나고 있는지에 대한 완전한 제어를 제공하는 경향이 있습니다. await 사용하면 연속 프로세스가 있는 지점을 지정할 수 있습니다. 또한 future 내부의 값을 unwrap 할 수 있습니다. 사용 측면에서 암시적 변환을 허용하면 다음과 같은 몇 가지 의미가 있습니다.

1. 우선, 이 동작을 에뮬레이트하려면 더러운 코드를 작성해야 합니다.
2. 이제 RLS와 IDE는 우리의 값이 Future<T> 이거나 T 자체를 기다리고 있다고 예상해야 합니다. 키워드 문제가 아닙니다. 존재하는 경우 결과는 T 이고, 그렇지 않으면 Future<T>
3. 코드를 이해하기 어렵게 만듭니다. 당신의 예에서는 get_status_updates 라인에서 실행을 중단하는 이유를 알 수 없지만 get_status_update 에서는 실행되지 않습니다. 그들은 서로 상당히 비슷합니다. 그래서 원래 코드가 작동하지 않거나 너무 복잡해서 주제에 대해 잘 알고 있어도 볼 수 없습니다. 두 대안 모두 이 옵션을 선호하지 않습니다.

여기에서 이 함수의 흐름이 무엇인지 알 수 없습니다. 여기서 는 대기가 완료될 때까지 실행이 중단되는 지점입니다.

네, 이것이 제가 "이것은 서스펜션 포인트를 더 보기 어렵게 만든다"는 말의 의미입니다. 연결된 내부 스레드를 읽으면 이것이 왜 그렇게 큰 문제가 아닌지에 대한 주장을 했습니다. 새 코드를 작성할 필요가 없습니다. 주석을 다른 위치에 넣기만 하면 됩니다( await 식 대신 async 블록). 십오은 아무 문제 유형이 무엇인지 이야기하지이 (가 항상 T 함수 호출 및 대한 Future<Output=T> 에 async 블록).

또한 구문에 관계없이 귀하의 이해가 틀릴 수 있음을 알려드립니다. Rust의 async 함수 는 어떤 식으로든 대기될 때까지 코드를 전혀 실행 b.Status != TaskStatus.RanToCompletion 검사는 항상 통과합니다. 이것은 RFC 스레드에서 죽을 때까지 논의되었습니다. 왜 이런 식으로 작동하는지 관심이 있는 경우입니다.

귀하의 예에서는 get_status_updates 행에서 실행을 중단하는 이유를 알 수 없지만 get_status_update 에서는 실행되지 않습니다. 그들은 서로 상당히 비슷합니다.

그것은 두 곳 모두에서 인터럽트 실행을 수행합니다. 핵심은 async 블록이 대기할 때까지 실행되지 않는다는 것입니다. 이는 위에서 설명한 대로 Rust의 모든 선물에 해당되기 때문입니다. 내 예에서, get_statuses 통화 (따라서 기다리고) get_status_updates , 다음 루프는 구축 (그러나 않습니다 await를하지 않음) count 선물, 그것은 기다리고 호출 (따라서 ) join_all , 이 시점에서 해당 선물은 동시에 get_status_update 호출합니다.

귀하의 예와의 유일한 차이점은 미래가 정확히 실행되기 시작하는 때입니다. 귀하의 경우에는 루프 중에 있습니다. 내에서는 join_all 동안입니다. 그러나 이것은 암시적 구문이나 async / await 와 전혀 관련이 없으며 Rust future가 작동하는 방식의 근본적인 부분입니다.

또한 구문에 관계없이 귀하의 이해가 틀릴 수 있음을 알려드립니다. Rust의 비동기 함수는 어떤 식으로든 기다릴 때까지 코드를 전혀 실행하지 않으므로 b.Status != TaskStatus.RanToCompletion 검사는 항상 통과합니다.

예, C# 작업은 첫 번째 일시 중단 지점까지 동기적으로 실행됩니다. 지적해주셔서 감사합니다.
그러나 나머지 메서드를 실행하는 동안 백그라운드에서 일부 작업을 실행할 수 있어야 하고 백그라운드 작업이 완료되었는지 확인할 수 있어야 하기 때문에 별로 중요하지 않습니다. 예를 들어

var a = await fooAsync(); // awaiting first task
var b = Task.Run(() => barAsync()); //running background task somehow
// the rest of the method is the same

async 블록에 대한 귀하의 아이디어가 있습니다. 제가 보기에 그것들은 같은 짐승이지만 더 많은 단점이 있습니다. 원래 제안에서 각 비동기 작업은 await 와 쌍을 이룹니다. async 블록을 사용하면 각 작업은 건설 지점에서 async 블록과 쌍을 이루므로 이전과 거의 동일한 상황(1:1 관계)에 있지만 조금 더 나빠집니다. 호출 사이트 동작이 컨텍스트에 따라 달라지기 때문에 더 부자연스럽고 이해하기 어렵습니다. await를 사용하면 let a = foo() 또는 let b = await foo() 를 볼 수 있으며 이 작업이 방금 구성되거나 구성되고 기다리고 있음을 알 수 있습니다. 내가 볼 경우 let a = foo() 와 async 블록 I가있는 경우 볼 필요가 일부 async 이상, 나는 때문에이 경우에는, 바로 당신을 얻을 경우

pub async fn get_statuses() -> Vec<StatusUpdate> {
    // get_status_updates is also an `async fn`, but calling it works just like any other call:
    let count = get_status_updates();

    let mut tasks = vec![];
    for i in 0..count {
        // Here is where task *construction* becomes explicit, as an async block:
        task.push(async {
            // Again, simply *calling* get_status_update looks just like a sync call:
            let status_update: StatusUpdateStruct = get_status_update(i).deserialize();
            StatusUpdate::new(utc_from_ticks(status_update.update_date), status_update.status_code, status_update.note))
        });
    }

    // And finally, launching the explicitly-constructed futures is also explicit, while awaiting the result is implicit:
    join_all(&tasks[..])
}

우리는 여기에 있는 동안 모든 작업을 한 번에 기다리고 있습니다.

pub async fn get_statuses() -> Vec<StatusUpdate> {
    // get_status_updates is also an `async fn`, but calling it works just like any other call:
    let count = get_status_updates();

    let mut tasks = vec![];
    for i in 0..count {
        // Isn't "just a construction" anymore
        task.push({
            let status_update: StatusUpdateStruct = get_status_update(i).deserialize();
            StatusUpdate::new(utc_from_ticks(status_update.update_date), status_update.status_code, status_update.note))
        });
    }
    tasks 
}

우리는 그것들을 하나가 되어 실행하고 있습니다.

따라서 이 부분의 정확한 동작이 무엇인지 말할 수 없습니다.

let status_update: StatusUpdateStruct = get_status_update(i).deserialize();
StatusUpdate::new(utc_from_ticks(status_update.update_date), status_update.status_code, status_update.note))

더 많은 컨텍스트 없이.

그리고 중첩된 블록을 사용하면 상황이 더 이상해집니다. 툴링 등에 대한 질문은 말할 것도 없습니다.

호출 사이트 동작은 컨텍스트에 따라 달라집니다.

이것은 이미 일반 동기화 코드와 클로저에 해당됩니다. 예를 들어:

// Construct a closure, delaying `do_something_synchronous()`:
task.push(|| {
    let data = do_something_synchronous();
    StatusUpdate { data }
});

대

// Execute a block, immediately running `do_something_synchronous()`:
task.push({
    let data = do_something_synchronous();
    StatusUpdate { data }
});

전체 암시적 await 제안에서 주의해야 할 또 다른 사항은 async 가 아닌 컨텍스트에서 async fn 호출할 수 없다는 것 입니다. 즉, some_function 가 async 인지 여부에 관계없이 함수 호출 구문 some_function(arg1, arg2, etc) 은 호출자가 계속되기 전에 some_function 의 본문을 완료할 때까지 항상 실행합니다. 따라서 async 컨텍스트에 대한 항목은 항상 명시적으로 표시되고 함수 호출 구문은 실제로 더 일관성이 있습니다.

await 구문 관련: 메서드 구문이 있는 매크로는 어떻습니까? 이것을 허용하는 실제 RFC를 찾을 수는 없지만 reddit에서 몇 가지 토론( 1 , 2 )을 찾았으므로 아이디어는 전례가 없습니다. 이렇게 하면 await 를 키워드로 만들지 않고 접미사 위치에서 작동할 수 있습니다 / 이 기능에 대해서만 새로운 구문을 도입합니다.

// Postfix await-as-a-keyword. Looks as if we were accessing a Result<_, _> field,
// unless await is syntax-highlighted
first().await?.second().await?.third().await?
// Macro with method syntax. A few more symbols, but clearly a macro invocation that
// can affect control flow
first().await!()?.second().await!()?.third().await!()?

모나드 구성을 단순화하는 Scala-world 라이브러리가 있습니다. http://monadless.io

Rust에게 흥미로운 아이디어가 있을지도 모릅니다.

문서에서 인용:

대부분의 주류 언어는 async/await 관용구를 사용하는 비동기 프로그래밍을 지원하거나 이를 구현하고 있습니다(예: F#, C#/VB, Javascript, Python, Swift). 유용하긴 하지만 async/await는 일반적으로 비동기 계산(Task, Future 등)을 나타내는 특정 모나드에 연결됩니다.

이 라이브러리는 async/await와 유사한 솔루션을 구현하지만 모든 모나드 유형으로 일반화됩니다. 이 일반화는 일부 코드베이스가 비동기식 계산을 위해 Future 외에 Task와 같은 다른 모나드를 사용한다는 점을 고려하는 주요 요소입니다.

M 모나드가 주어지면 일반화에서는 일반 값을 모나드로 들어올리는 개념( T => M[T] )과 모나드 인스턴스에서 값을 해제하는 개념( M[T] => T )을 사용합니다. > 사용 예:

lift {
  val a = unlift(callServiceA())
  val b = unlift(callServiceB(a))
  val c = unlift(callServiceC(b))
  (a, c)
}

리프트는 async 및 unlift to wait에 해당합니다.

이것은 이미 일반 동기화 코드와 클로저에 해당됩니다. 예를 들어:

여기에 몇 가지 차이점이 있습니다.

1. Lambda 컨텍스트는 피할 수 없지만 await 용 await 에는 컨텍스트가 없고 async 에는 컨텍스트가 있어야 합니다. 전자는 동일한 기능을 제공하지만 코드에 대해 덜 알아야 하기 때문에 승리합니다.
2. 람다는 짧아서 기껏해야 여러 줄로 되어 있어 몸 전체를 한 번에 볼 수 있고 단순합니다. async 함수는 상당히 크고(일반 함수만큼 크며) 복잡할 수 있습니다.
3. Lambda는 거의 중첩되지 않으며( then 호출을 제외하고는 await 가 제안됨) async 블록은 자주 중첩됩니다.

전체 암시적 대기 제안에서 주의해야 할 또 다른 사항은 비동기 컨텍스트에서 async fns를 호출할 수 없다는 것입니다.

흠, 나는 그것을 눈치 채지 못했습니다. 내 연습에서는 종종 비동기가 아닌 컨텍스트에서 비동기를 실행하기를 원하기 때문에 좋게 들리지 않습니다. C#에서 async 는 컴파일러가 함수 본문을 다시 작성할 수 있도록 하는 키워드일 뿐이며 함수 인터페이스에 어떤 영향도 미치지 않으므로 async Task<Foo> 및 Task<Foo> 는 완전히 상호 교환 가능하며 구현과 API를 분리합니다.

때로는 async 작업을 차단하고 싶을 수도 있습니다(예: main 에서 일부 네트워크 API를 호출하려는 경우). 차단해야 하지만(그렇지 않으면 OS로 돌아가 프로그램이 종료됨) 비동기 HTTP 요청을 실행해야 합니다. main 를 해킹하여 비동기가 되도록 하는 것과 Result 기본 반환 유형을 사용하는 경우를 제외하고 여기에 어떤 솔루션이 있는지 잘 모르겠습니다

현재 await 에 찬성하는 또 다른 고려 사항은 다른 인기 있는 언어에서 작동하는 방식입니다( @fdietze 에서 언급

여기에서 몇 가지 차이점이 보입니다.

또한 기본 RFC에는 암시적 버전과 동일한 의미를 가진 async 블록이 이미 있음을 알아야 합니다.

내 연습에서는 종종 비동기가 아닌 컨텍스트에서 비동기를 실행하기를 원하기 때문에 좋게 들리지 않습니다.

이것은 문제가 아닙니다. 당신은 여전히 사용할 수 있습니다 async 비에 블록 async (그들은 단지로 평가하기 때문에 잘되는 상황을 F: Future 언제나처럼), 당신은 선물 또는 블록 산란 여전히 수 이전과 정확히 동일한 API를 사용합니다.

당신은 호출 할 수 없습니다 async fn 들 대신에 그들에게 전화를 포장 async 블록 - 당신이 원하는 경우에 당신이 상관없이,에있어 문맥의 수행으로 F: Future .

async는 컴파일러가 함수 본문을 다시 작성할 수 있도록 하는 키워드일 뿐이며 어떤 식으로든 함수 인터페이스에 영향을 미치지 않습니다.

예, 이것은 제안 간의 합법적인 차이입니다. 내부 스레드에서도 덮여있었습니다. 틀림없이, async fn 버전은 구성의 일부로 코드를 실행하지 않는 반면 -> impl Future 버전은 예를 들어 사용자에게 제공하기 전에 요청을 시작할 수 있음을 보여주기 때문에 둘에 대해 서로 다른 인터페이스를 갖는 것이 유용합니다. F: Future . 또한 수 async fn 의 정상과 일관성 fn 호출 뭔가로 선언 된 것을들에서 -> T 항상 당신에게 줄 것이다 T , 관계없이 여부의 async .

(Rust에서는 RFC에 설명된 대로 async fn 와 Future 반환 버전 사이에 여전히 상당한 도약 이 있음을 주목해야 합니다. async fn 버전에서는 언급하지 않습니다. Future 서명의 아무 곳이나 필요하고 수동 버전에는 impl Trait 가 필요하며 이는 수명과 관련된 몇 가지 문제를 수반합니다. 이것은 실제로 async fn 에 대한 동기의 일부입니다

C#/TypeScript/JS/Python과 같은 다른 언어에서 쉽게 마이그레이션할 수 있습니다.

이것은 리터럴 await future 구문 에만 이점이 있으며, 이는 Rust 자체에서 상당히 문제가 됩니다. 우리가 끝낼 수 있는 다른 모든 것 역시 해당 언어와 불일치하는 반면 암시적 await는 최소한 a) Kotlin과의 유사점 및 b) 동기식 스레드 기반 코드와의 유사점을 가지고 있습니다.

예, 이것은 제안 간의 합법적인 차이입니다. 내부 스레드에서도 덮여있었습니다. 틀림없이 둘에 대해 서로 다른 인터페이스를 갖는 것이 유용합니다.

구현 세부 사항에 의존하는 API를 갖는 것은 나에게 좋지 않게 들리기 때문에 _두 가지에 대해 서로 다른 인터페이스를 갖는 것이 몇 가지 장점이 있다고 말하고 싶습니다. 예를 들어, 단순히 내부 future에 대한 호출을 위임하는 계약을 작성하고 있습니다.

fn foo(&self) -> Future<T> {
   self.myService.foo()
}

그런 다음 일부 로깅을 추가하고 싶습니다.

async fn foo(&self) -> T {
   let result = await self.myService.foo();
   self.logger.log("foo executed with result {}.", result);
   result
}

그리고 그것은 획기적인 변화가 됩니다. 와?

이것은 리터럴 await future 구문에만 이점이 있으며, 이는 Rust 자체에서 상당히 문제가 됩니다. 우리가 끝낼 수 있는 다른 모든 것 역시 해당 언어와 불일치하는 반면 암시적 await는 최소한 a) Kotlin과의 유사점 및 b) 동기식 스레드 기반 코드와의 유사점을 가지고 있습니다.

await 구문, await foo / foo await / foo@ / foo.await /... 동일하지만 유일한 차이점은 앞/뒤에 배치하거나 키워드 대신 인장을 갖는다는 것입니다.

또한 RFC에 설명된 대로 Rust에서는 async fn과 Future-returning 버전 사이에 여전히 상당한 도약이 있음을 알아야 합니다.

나는 그것을 알고 있고 그것은 나를 많이 불안하게 한다.

그리고 그것은 획기적인 변화가 됩니다.

async 블록을 반환하여 이 문제를 해결할 수 있습니다. 암시적 대기 제안에서 예제는 다음과 같습니다.

fn foo(&self) -> impl Future<Output = T> { // Note: you never could return `Future<T>`...
    async { self.my_service.foo() } // ...and under the proposal you couldn't call `foo` outside of `async` either.
}

그리고 로깅:

fn foo(&self) -> impl Future<Output = T> {
    async {
        let result = self.my_service.foo();
        self.logger.log("foo executed with result {}.", result);
        result
    }
}

이러한 구분에 대한 더 큰 문제는 수동 미래 구현 및 결합기(오늘날 유일한 방법)에서 async/await로 생태계를 전환하는 동안 발생합니다. 그러나 그때에도 제안을 통해 이전 인터페이스를 유지하고 그와 함께 새로운 비동기 인터페이스를 제공할 수 있습니다. 예를 들어 C#은 그 패턴으로 가득 차 있습니다.

글쎄, 그것은 합리적으로 들린다.

그러나 나는 그러한 암시적(여기서 foo() 이 비동기 또는 동기화 기능인지 알 수 없음)이 COM+와 같은 프로토콜에서 발생하는 동일한 문제를 야기하고 WCF가 그대로 구현되는 이유라고 믿습니다

이 코드는 비동기인지 동기화인지 일부 요청이 있는지 확인할 수 없다는 점을 제외하면 완벽하게 괜찮아 보입니다. 중요한 정보라고 생각합니다. 예를 들어:

fn foo(&self) -> impl Future<Output = T> {
    async {
        let result = self.my_service.foo();
        self.logger.log("foo executed with result {}.", result);
        let bars: Vec<Bar> = Vec::new();
        for i in 0..100 {
           bars.push(self.my_other_service.bar(i, result));
        }
        result
    }
}

bar 가 동기화 또는 비동기 기능인지 아는 것이 중요합니다. 루프에서 await 가 로드와 성능 전반에 걸쳐 더 나은 결과를 얻으려면 이 코드를 변경해야 한다는 표시로 자주 봅니다. 이것은 내가 어제 검토한 코드입니다(코드는 차선책이지만 검토 반복 중 하나임).

보시다시피 여기에서 루핑이 기다리고 있음을 쉽게 발견하고 변경을 요청했습니다. 변경 사항이 커밋되었을 때 페이지 로드 속도가 3배 향상되었습니다. await 없이는 이 잘못된 행동을 쉽게 간과할 수 있습니다.

나는 Kotlin을 사용하지 않았다는 것을 인정하지만 지난번에 그 언어를 보았을 때 기계적으로 하나를 다른 것으로 번역하기 쉬운 지점까지 구문이 적은 Java의 변형인 것 같았습니다. 나는 또한 그것이 Java의 세계(약간 구문이 무거운 경향이 있음)에서 선호되는 이유를 상상할 수 있으며, 특히 Java가 아니기 때문에 최근에 인기가 높아졌다는 것을 알고 있습니다(Oracle 대 Google 상황 ).

그러나 인기도와 친숙도를 고려하기로 결정했다면 JavaScript가 하는 일을 살펴보고 싶을 수도 있습니다. 이는 await 이기도 합니다.

즉, await 는 C#에 의해 주류 언어에 도입되었습니다. C#은 사용 편의성이 가장 중요하게 여겨지는 언어 중 하나일 것입니다. C#에서 비동기 호출은 await 키워드뿐만 아니라 메서드 호출의 Async 접미사로도 표시됩니다. await , yield return 와 가장 많이 공유되는 다른 언어 기능도 코드에서 두드러지게 볼 수 있습니다.

왜 그런 겁니까? 제 생각은 제너레이터와 비동기식 호출이 코드에서 눈에 띄지 않게 전달되도록 하기에는 너무 강력한 구조라는 것입니다. 제어 흐름 연산자의 계층이 있습니다.

• 명령문의 순차적 실행(암시적)
• 함수/메서드 호출(매우 분명함, 예를 들어 호출 사이트에서 nullary 함수와 변수 사이에 차이가 없는 Pascal 와 비교)
• goto (좋아요, 엄격한 계층 구조는 아닙니다)
• 제너레이터( yield return 가 눈에 띄는 경향이 있음)
• await + Async 접미사

표현력이나 힘에 따라 그것들이 덜 장황한 것으로부터 어떻게 더 장황하게 변하는지 주목하십시오.

물론 다른 언어는 다른 접근 방식을 취했습니다. (에서와 같은 제도의 연속성을 call/cc 에서 너무 다르지 않다, await 또는 매크로)를 호출하는 것을 보여 어떤 구문이 없습니다. 매크로의 경우 Rust는 매크로를 쉽게 볼 수 있도록 접근했습니다.

따라서 구문이 더 적은 것은 그 자체로 바람직하지 않으며(이를 위해 APL 또는 Perl과 같은 언어가 있음) 해당 구문이 상용구일 필요는 없으며 가독성에 중요한 역할을 한다고 주장합니다.

사람들은 새로운 기능이 있을 때 시끄러운 구문을 사용하는 것이 더 편안하지만 다음에는 괜찮습니다. 일반적으로 사용되면 덜 장황합니다.

await!(foo)? 대 await foo? 의 질문에 관해서는 저는 이전 캠프에 있습니다. 거의 모든 구문을 내부화할 수 있지만 우리는 간격과 근접에서 신호를 받는 데 너무 익숙합니다. await foo? 를 사용하면 중괄호가 무슨 일이 일어나고 있는지 명확하게 하는 동안 두 연산자의 우선 순위를 스스로 추측할 가능성이 있습니다. 3명의 캐릭터를 구하는 것은 가치가 없습니다. 그리고 await! 를 연결하는 연습에 관해서는 일부 언어에서 널리 사용되는 관용구일 수 있지만 최적화할 가치가 있는 가독성 및 디버거와의 상호 작용과 같은 단점이 너무 많다고 생각합니다.

3명의 캐릭터를 구하는 것은 가치가 없습니다.

내 일화적인 경험에 따르면 추가 문자(예: 더 긴 이름)는 그다지 문제가 되지 않지만 추가 토큰은 정말 짜증날 수 있습니다. CPU 비유와 관련하여 긴 이름은 지역성이 좋은 직선 코드입니다. 근육 메모리에서 그냥 입력할 수 있습니다. 반면에 여러 토큰(예: 구두점)과 관련된 동일한 수의 문자는 가지가 없고 캐시 누락으로 가득 차 있습니다.

( await foo? 는 매우 명확하지 않으며 이를 피해야 하며 더 많은 토큰을 입력해야 한다는 점에 전적으로 동의합니다. 제 관찰에 따르면 모든 문자가 동일하게 생성되지는 않습니다.)

@rpjohnst 나는 당신의 대안 제안이 "암시적 대기"가 아닌 "명시적 비동기"로 제시된다면 약간 더 나은 수용을 받을 수 있다고 생각합니다 :-)

bar 가 동기화 또는 비동기 기능인지 아는 것이 중요합니다.

나는 이것이 어떤 함수가 싸거나 비싼지, IO를 하는지 아닌지, 또는 그것이 어떤 전역 상태에 닿는지 아닌지를 아는 것과 정말로 다른지 잘 모르겠습니다. (이는 @lnicola 의 계층 구조에도 적용됩니다. 비동기 호출이 동기화 호출처럼 완료될 때까지 실행된다면 전력 측면에서 실제로 다르지 않습니다!)

예를 들어, 호출이 루프에 있었다는 사실은 그것이 비동기라는 사실보다 더 중요하지는 않지만 중요합니다. 그리고 병렬화가 훨씬 쉬워진 Rust에서는 값비싼 동기 루프를 Rayon 반복자로 전환하도록 제안할 수도 있습니다!

따라서 await 요구하는 것이 실제로 이러한 최적화를 포착하는 데 그렇게 중요하다고 생각하지 않습니다. 루프는 이미 최적화를 찾기에 항상 좋은 위치이며 async fn 는 이미 저렴한 IO 동시성을 얻을 수 있다는 좋은 지표입니다. 이러한 기회를 놓치고 있다면 가끔 실행하는 "루프의 비동기 호출"에 대해 Clippy 린트를 작성할 수도 있습니다. 동기 코드에도 비슷한 보푸라기가 있으면 좋을 것입니다!

"명시적 비동기화"에 대한 동기는 @lnicola가 암시하는 것처럼 단순히 "적은 구문"이 아닙니다. foo() 항상 foo 의 본문을 완료할 때까지 실행하도록 함수 호출 구문의 동작을 보다 일관되게 만들기 위한 것입니다. 이 제안에 따라 주석을 생략하면 거의 모든 코드가 이미 작동하는 방식인 덜 동시적인 코드가 제공됩니다. "명시적 대기"에서 주석을 생략하면 문제가 되는 우연한 동시성 또는 최소한 우연한 인터리빙이 발생합니다.

귀하의 대체 제안이 "암시적 대기"가 아닌 "명시적 비동기"로 제시된다면 수신이 약간 더 좋을 수 있다고 생각합니다 :-)

스레드의 이름은 "명시적 미래 구성, 암시적 기다림"이지만 후자의 이름이 고정된 것 같습니다. :피

나는 이것이 어떤 함수가 싸거나 비싼지, IO를 하는지 아닌지, 또는 그것이 어떤 전역 상태에 닿는지 아닌지를 아는 것과 정말로 다른지 잘 모르겠습니다. (이는 @lnicola 의 계층 구조에도 적용됩니다. 비동기 호출이 동기화 호출처럼 완료될 때까지 실행된다면 전력 측면에서 실제로 다르지 않습니다!)

나는 이것이 함수가 어떤 상태를 변경한다는 것을 아는 것만큼 중요하다고 생각하고 우리는 이미 호출자 측에 mut 키워드를 가지고 있습니다.

"명시적 비동기화"에 대한 동기는 @lnicola가 암시하는 것처럼 단순히 "적은 구문"이 아닙니다. foo()가 항상 foo의 본문을 완료하도록 실행하도록 함수 호출 구문의 동작을 보다 일관되게 만들기 위한 것입니다.

한편으로는 좋은 평가입니다. 다른 하나에서는 미래 생성과 미래 실행을 쉽게 분리할 수 있습니다. foo 가 run 를 호출하고 결과를 얻을 수 있는 추상화를 반환하면 foo 아무것도 하지 않는 쓸모없는 쓰레기가 되지 않습니다. 유용한 점: 나중에 메서드를 호출할 수 있는 일부 개체를 구성합니다. 그것은 그것을 다르게 만들지 않습니다. 우리가 호출하는 foo 메소드는 단지 블랙박스이고 서명 Future<Output=T> 를 보고 실제로 미래를 반환합니다. 그래서 우리는 그것을 원할 때 명시적으로 await 합니다.

스레드의 이름은 "명시적 미래 구성, 암시적 기다림"이지만 후자의 이름이 고정된 것 같습니다. :피

나는 개인적으로 더 나은 대안이 "명시적 비동기 명시적 대기"라고 생각합니다. :)

추신

나는 또한 오늘 밤 한 생각에 사로잡혔다. C# LDM과 통신을 시도했습니까? 예를 들어 @HaloFour , @gafter 또는 @CyrusNajmabadi 와 같은 사람입니다. 그들이 왜 그들이 취한 구문을 취했는지 묻는 것은 정말 좋은 생각일 것입니다. 다른 언어를 사용하는 사람들에게도 물어볼 것을 제안하고 싶지만 저는 그냥 모릅니다. :) 그들은 기존 구문에 대해 여러 번 토론했으며 이미 많은 토론을 할 수 있었고 유용한 아이디어가 있을 수 있습니다.

이것은 C#이 있기 때문에 러스트가 이 구문을 가져야 한다는 것을 의미하지는 않지만, 더 가중치를 둔 결정을 내릴 수 있게 해줍니다.

나는 개인적으로 더 나은 대안이 "명시적 비동기 명시적 대기"라고 생각합니다. :)

주요 제안 은 "명시적 비동기" 암시적 비동기"입니다. 주석이 없는 함수 호출은 Future 가 서명 어디에도 나타나지 않더라도 미래를 기다리지 않고 생성할 수 있습니다.

가치가 있기 때문에 내부 스레드에는 "명시적 비동기 명시적 대기" 대안 이 포함되어 있습니다. (첫 번째 게시물의 마지막 섹션을 참조하십시오.)

C# LDM과 통신을 시도 했습니까?

주요 RFC의 작성자가 그랬습니다. 내가 기억하는 한 그것에서 나온 요점은 async fn 의 서명에 Future 를 포함하지 않기로 결정했다는 것입니다. C#에서는 Task 를 다른 유형으로 대체하여 함수가 구동되는 방식을 어느 정도 제어할 수 있습니다. 그러나 Rust에서는 그러한 메커니즘이 없습니다(그리고 앞으로도 없을 것입니다). 모든 퓨처는 단일 특성을 거치므로 매번 해당 특성을 작성할 필요가 없습니다.

우리는 또한 Dart 언어 디자이너들과 의사소통을 했고 이것이 "명시적 비동기" 제안을 작성하게 된 동기의 큰 부분이었습니다. Dart 1은 함수 가 호출될 때 첫 번째 await로 실행 할 수 없지만, 호출될 때 전체 함수를 실행할 수 있으므로 혼란을 피할 수도 있습니다.

우리는 또한 Dart 언어 디자이너들과 의사소통을 했고 이것이 "명시적 비동기" 제안을 작성하게 된 동기의 큰 부분이었습니다. Dart 1은 함수가 호출될 때 첫 번째 await로 실행되지 않았기 때문에 문제가 있었고(Rust가 작동하는 방식과 완전히 같지는 않지만 비슷함) 엄청난 혼란을 야기하여 Dart 2에서는 함수가 처음으로 실행되도록 변경했습니다. 호출될 때 기다립니다. Rust는 다른 이유로 그렇게 할 수 없지만, 호출될 때 전체 함수를 실행할 수 있으므로 혼란을 피할 수도 있습니다.

좋은 경험, 나는 그것을 알지 못했습니다. 이렇게 엄청난 일을 하셨다니 반갑습니다. 잘했어 👍

나는 또한 오늘 밤 한 생각에 사로잡혔다. C# LDM과 통신을 시도했습니까? 예를 들어 @HaloFour , @gafter 또는 @CyrusNajmabadi 와 같은 사람입니다. 그들이 왜 그들이 취한 구문을 취했는지 묻는 것은 정말 좋은 생각일 것입니다.

나는 당신이 관심 있는 정보를 제공하게 되어 기쁩니다. 그러나 나는 단지 그것을 훑어본 것뿐입니다. 현재 가지고 있는 특정 질문을 요약할 수 있습니까?

await 구문과 관련하여(이것은 완전히 어리석은 것일 수 있습니다. 부담 없이 저에게 소리를 지르십시오. 저는 비동기 프로그래밍 멍청한 놈이고 제가 무슨 말을 하는지 전혀 모릅니다):

"await"라는 단어를 사용하는 대신 ? 와 유사한 기호/연산자를 도입할 수 없습니다. 예를 들어, # 또는 @ 또는 현재 사용되지 않는 다른 것일 수 있습니다.

예를 들어 후위 연산자인 경우:

let stuff = func()#?;
let chain = blah1()?.blah2()#.blah3()#?;

매우 간결하고 자연스럽게 왼쪽에서 오른쪽으로 읽습니다. 먼저 대기( # )한 다음 오류를 처리합니다( ? ). .await 가 구조체 멤버처럼 보이는 postfix await 키워드에 문제가 없습니다. # 는 분명히 연산자입니다.

postfix가 적절한 위치인지는 모르겠지만 우선 순위 때문에 그렇게 느꼈습니다. 접두사로:

let stuff = #func()?;

아니면 도대체:

let stuff = func#()?; // :-D :-D

이것이 논의된 적이 있습니까?

(나는 이것이 Perl이 악명 높은 "기호의 무작위 키보드 매쉬" 구문에 접근하기 시작한다는 것을 알고 있습니다 ... :-D )

@rayvector https://github.com/rust-lang/rust/issues/50547#issuecomment -388108875 , 다섯 번째 대안.

@CyrusNajmabadi 와 주셔서 감사합니다. 주요 질문은 나열된 옵션 중에서 현재의 Rust 언어가 있는 그대로 더 잘 맞는다고 생각하는 옵션이 무엇입니까, 아니면 다른 대안이 있습니까? 이 주제는 그다지 길지 않으므로 위에서 아래로 빠르게 스크롤할 수 있습니다. 주요 질문: Rust는 현재 C#/TS/... await 방식을 따라야 합니까 아니면 자체적으로 구현해야 합니다. 현재 구문은 어떤 식으로든 변경하고 싶은 일종의 "레거시"입니까, 아니면 C#에 가장 적합하고 새로 등장하는 언어에도 가장 적합한 옵션입니까?

C# 구문에 대한 주요 고려 사항은 연산자 우선 순위 await foo? 가 먼저 대기한 다음 ? 연산자를 평가하고 C# 실행이 처음 await 까지 호출자 스레드에서 실행되지 않는다는 차이점입니다 GetEnumerator 가 처음으로 호출될 때까지 부정성 검사를 실행하지 않습니다.

IEnumerable<int> GetInts(int n)
{
   if (n < 0)
      throw new InvalidArgumentException(nameof(n));
   for (int i = 0; i <= n; i++)
      yield return i;
}

내 첫 번째 의견 과 이후 토론에서 더 자세히 설명합니다.

@Pzixel 오,

어쨌든, 나는 그 짧은 언급 외에는 이것에 대한 많은 토론을 보지 못했습니다.

찬성/반대하는 좋은 논거가 있습니까?

@rayvector 더 자세한 구문에 찬성하여 여기 에서 약간 논쟁했습니다. 그 이유 중 하나는 다음과 같이 언급한 것입니다.

Perl이 악명 높은 "기호의 무작위 키보드 매쉬" 구문

명확히 하자면, await!(f)? 가 실제로 최종 구문을 위해 실행되고 있다고 생각하지 않습니다. 특정 선택을 커밋하지 않는 확실한 방법이기 때문에 특별히 선택되었습니다. 다음은 아직 "실행 중"이라고 생각되는 구문( ? 연산자 포함)입니다.

• await f?
• await? f
• await { f }?
• await(f)?
• (await f)?
• f.await?

또는 아마도 이들의 일부 조합. 요점은 그들 중 일부가 우선 순위에 대해 더 명확하게 하기 위해 중괄호를 포함하고 여기에 많은 옵션이 있다는 것입니다. 그러나 의도는 await 가 최종 버전에서 매크로가 아닌 키워드 연산자가 될 것이라는 것입니다( rpjohnst가 제안한 것과 같은 일부 주요 변경 사항을 제외).

나는 간단한 후위 await 연산자(예: ~ ) 또는 괄호가 없고 우선 순위가 가장 높은 키워드에 투표합니다.

나는 이 스레드를 읽고 있었고 다음을 제안하고 싶습니다.

• await f? 는 먼저 ? 연산자를 평가한 다음 결과 미래를 기다립니다.
• (await f)? 는 먼저 미래를 기다린 다음 결과에 대해 ? 연산자를 평가합니다(일반 Rust 연산자 우선 순위로 인해)
• await? f 는 `(await f)?에 대한 구문 설탕으로 사용할 수 있습니다. 나는 "미래에 결과를 반환하는 것"이 ​​매우 일반적인 경우가 될 것이라고 생각하므로 전용 구문이 의미가 있습니다.

나는 await 가 명시적이어야 한다는 다른 논평자들의 의견에 동의합니다. JavaScript에서 이 작업을 수행하는 것은 꽤 힘들고 Rust 코드의 명시성과 가독성에 정말 감사합니다. 비동기식을 암시적으로 만들면 비동기식 코드에서 이 작업을 망칠 것 같습니다.

"암시적 비동기 블록"은 미래 앞에 await 키워드를 삽입하는 proc_macro로 구현 가능해야 한다는 생각이 들었습니다.

주요 질문은 나열된 옵션 중에서 현재 Rust 언어가 있는 그대로 더 잘 맞는다고 생각하는 옵션이 무엇이냐는 것입니다.

Rust 언어에 가장 적합한 것이 무엇인지 C# 디자이너에게 묻는 것은... 흥미롭습니다. :)

나는 그런 결정을 내릴 자격이 없다고 느낀다. 나는 녹을 좋아하고 그것에 손을 대고 있습니다. 그러나 그것은 내가 매일 사용하는 언어가 아닙니다. 내 정신에 깊이 뿌리내린 적도 없다. 따라서 여기에서 이 언어에 대한 적절한 선택이 무엇인지 주장할 자격이 없다고 생각합니다. Go/TypeScript/C#/VB/C++에 대해 묻고 싶습니다. 물론, 훨씬 더 편안하게 느낄 것입니다. 그러나 녹은 그러한 생각에 편안함을 느끼기에는 너무 전문적인 영역을 벗어났습니다.

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

이것은 내가 댓글을 달 수 있다고 느끼는 것입니다. 우리는 'wait'로 우선순위에 대해 많이 생각했고 원하는 형태를 설정하기 전에 많은 형태를 시도했습니다. 우리가 찾은 핵심 사항 중 하나는 우리와 이 기능을 사용하고자 하는 고객(내부 및 외부)에게 사람들이 비동기 호출 이후에 무엇이든 '연결'하고 싶어하는 경우가 거의 없다는 것입니다. 다시 말해, 사람들은 완전한 표현의 가장 중요한 부분인 '기다림'에 대해 강하게 끌리는 것처럼 보였고 따라서 그것을 정상 가까이에 두는 것 같았습니다. 참고: '전체 표현식'이란 표현식의 맨 위에 있는 표현식이나 최상위 할당 오른쪽에 있는 표현식 또는 '인수'로 전달하는 표현식과 같은 것을 의미합니다.

사람들이 expr 내부에서 'await'로 '계속'하고 싶어하는 경향은 드뭅니다. (await expr).M() 와 같은 것을 가끔 볼 수 있지만 await expr.M() 하는 사람들보다 덜 일반적이고 덜 바람직해 보입니다.

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

지금까지, 우리는 우리의 고객을위한 우선 순위 선택에 매우 행복했습니다. 앞으로 여기에서 약간의 변경을 할 수 있습니다. 그러나 전반적으로 그렇게 해야 한다는 강한 압력은 없습니다.

--

뿐만 아니라 C# 실행이 처음 await 때까지 호출자 스레드에서 실행되지 않지만 전혀 시작되지 않는다는 차이점과 마찬가지로 현재 코드 조각은 GetEnumerator가 처음 호출될 때까지 부정성 검사를 실행하지 않습니다.

IMO, 우리가 열거하는 방식은 약간의 실수였으며 수년 동안 많은 혼란을 야기했습니다. 많은 코드가 다음과 같이 작성되어야 하는 경향 때문에 특히 나쁩니다.

```c#
무효 SomeEnumerator(X 인수)
{
// Args의 유효성을 검사하고 동기 작업을 수행합니다.
반환 SomeEnumeratorImpl(인수);
}

무효 SomeEnumeratorImpl(X 인수)
{
// ...
생산하다
// ...
}

People have to write this *all the time* because of the unexpected behavior that the iterator pattern has.  I think we were worried about expensive work happening initially.  However, in practice, that doesn't seem to happen, and people def think about the work as happening when the call happens, and the yields themselves happening when you actually finally start streaming the elements.

Linq (which is the poster child for this feature) needs to do this *everywhere*, this highly diminishing this choice.

For ```await``` i think things are *much* better.  We use 'async/await' a ton ourselves, and i don't think i've ever once said "man... i wish that it wasn't running the code synchronously up to the first 'await'".  It simply makes sense given what the feature is.  The feature is literally "run the code up to await points, then 'yield', then resume once the work you're yielding on completes".  it would be super weird to not have these semantics to me since it is precisely the 'awaits' that are dictating flow, so why would anything be different prior to hitting the first await.

Also... how do things then work if you have something like this:

```c#
async Task FooAsync()
{
    if (cond)
    {
        // only await in method
        await ...
    }
} 

이 메서드를 완전히 호출하고 await를 누르지 않아도 됩니다. "먼저 기다릴 때까지 호출자 스레드에서 실행이 실행되지 않는 경우" 여기서 실제로 어떤 일이 발생합니까?

기다리다? f는 `(await f)?에 대한 구문 설탕으로 사용할 수 있습니다. 나는 "미래에 결과를 반환하는 것"이 ​​매우 일반적인 경우가 될 것이라고 생각하므로 전용 구문이 의미가 있습니다.

이것이 가장 공감이 갑니다. 이는 'await'가 최상위 개념이 되도록 허용하지만 결과 유형을 간단하게 처리할 수도 있습니다.

C#에서 우리가 알고 있는 한 가지는 우선 순위에 대한 사람들의 직관이 공백에 묶여 있다는 것입니다. 따라서 "x를 기다리시겠습니까?" ? 가 표현식에 인접하기 때문에 await 가 ? 보다 우선 순위가 낮은 것처럼 즉시 느껴집니다. 위의 내용이 실제로 (await x)? 로 구문 분석되면 청중이 놀랄 것입니다.

await (x?) 로 구문 분석하는 것이 구문에서 가장 자연스럽게 느껴지고 미래/작업의 '결과'를 다시 얻고 실제로 값을 받은 경우 이를 '기다려'야 할 필요성에 적합합니다. . 그런 다음 결과 자체를 반환했다면 이후에 발생했음을 알리기 위해 'await'와 결합하는 것이 적절하다고 생각합니다. 따라서 await? x? 각 ? 는 가장 자연스럽게 관련된 코드 부분에 단단히 바인딩됩니다. 첫 번째 ? 는 await (특히 그 결과)와 관련되고 두 번째 x 됩니다.

"먼저 기다릴 때까지 호출자 스레드에서 실행이 실행되지 않는 경우" 여기서 실제로 어떤 일이 발생합니까?

호출자의 반환 값 기다립니다 때까지 아무런 반응이 없습니다 FooAsync 하는 포인트, FooAsync 의 몸이 실행될 때까지 어느 쪽 await 하거나 반환합니다.

Rust Future 는 poll 대한 첫 번째 호출 이후에 폴 기반, 스택 할당 및 움직일 수 없기 때문에 이런 식으로 작동합니다. 호출자는 최상위 Future 의 힙 또는 상위 Future 내부의 값에 따라 종종 "스택 프레임"에 있는 위치로 이동할 기회가 있어야 합니다 Future async fn 호출 중 -- 코드가 실행되기 전에.

이것은 우리가 a) 호출 시 코드가 실행되지 않는 C# 생성기와 유사한 의미 체계 또는 b) 함수 호출 도 즉시 암시적으로 함수 async { .. } )에 갇혀 있음을 의미합니다.

나는 C# 생성기에서 언급한 문제를 피하고 연산자 우선 순위 질문을 완전히 피하기 때문에 후자를 선호합니다.

@CyrusNajmabadi Rust에서 Future 일반적으로 Task 로 생성될 때까지 작동하지 않습니다(F# Async 와 훨씬 유사함):

let bar = foo();

이 경우 foo() 는 Future 반환하지만 실제로 는 아무 것도 하지 않을 것입니다. 수동으로 생성해야 합니다(F# Async 와 유사함).

tokio::run(bar);

생성되면 Future 를 실행합니다. 이것이 Future 의 기본 동작이므로 Rust에서 async/await가 생성될 때까지 코드를 실행하지 않는 것이 더 일관됩니다.

분명히 C#에서는 상황이 다릅니다. C#에서는 foo() 를 호출하면 즉시 Task 실행을 시작하므로 C#에서는 처음 await 까지 코드를 실행하는 것이 합리적입니다. .

또한 ... 이와 같은 것이 있으면 어떻게 작동합니까 [...] 이 메서드를 완전히 호출하고 대기를 누르지 않을 수 있습니다. "먼저 기다릴 때까지 호출자 스레드에서 실행이 실행되지 않는 경우" 여기서 실제로 어떤 일이 발생합니까?

FooAsync() 를 호출하면 아무 작업도 수행하지 않고 코드가 실행되지 않습니다. 그런 다음 그것을 생성할 때 코드를 동기적으로 실행하고 await 는 절대 실행되지 않으므로 즉시 () (Rust의 void 버전)를 반환합니다.

즉, "첫 번째 await 때까지 호출자 스레드에서 실행되지 않음"이 아니라 "명시적으로 생성될 때까지 실행되지 않음(예: tokio::run )"입니다.

호출자가 FooAsync의 반환 값을 기다릴 때까지 아무 일도 일어나지 않으며, 이때 FooAsync의 본체는 await 또는 반환될 때까지 실행됩니다.

이크. 불행한 것 같습니다. (종종 취소 및 작업 구성으로 인해) 무언가를 기다리지 못할 때가 많습니다. 개발자로서 나는 여전히 초기 오류를 얻는 것에 감사하고 있습니다(사람들이 대기까지 실행하기를 원하는 가장 일반적인 이유 중 하나입니다).

이것은 우리가 a) 호출 시 코드가 실행되지 않는 C# 생성기와 유사한 의미 체계 또는 b) 함수 호출도 즉시 암시적으로 함수를 기다리는 Kotlin 코루틴과 같은 의미 체계(클로저와 유사한 async { 사용)에 갇혀 있음을 의미합니다. . } 동시 실행이 필요한 경우를 위한 블록).

이러한 점을 감안할 때 나는 후자보다 전자를 훨씬 선호합니다. 다만 제 개인적인 취향입니다. kotlin 접근 방식이 도메인에 더 자연스럽게 느껴진다면 그렇게 하세요!

@CyrusNajmabadi Ick. 불행한 것 같습니다. (종종 취소 및 작업 구성으로 인해) 무언가를 기다리지 못할 때가 많습니다. 개발자로서 나는 여전히 초기 오류를 얻는 것에 감사하고 있습니다(사람들이 대기까지 실행하기를 원하는 가장 일반적인 이유 중 하나입니다).

나는 정반대를 느낀다. JavaScript에 대한 제 경험에 따르면 await 를 사용하는 것을 잊는 것은 매우 일반적입니다. 이 경우 Promise 는 계속 실행되지만 오류는 무시됩니다(또는 다른 이상한 일이 발생함).

Rust/Haskell/F# 스타일을 사용하면 Future 가 실행되거나(올바른 오류 처리와 함께) 실행되지 않습니다. 그런 다음 실행되고 있지 않음을 확인하고 조사하고 수정합니다. 나는 이것이 더 강력한 코드를 만든다고 믿습니다.

@Pauan @rpjohnst 설명 감사합니다. 그것들은 우리도 고려한 접근 방식이었습니다. 그러나 실제로는 그렇게 바람직하지 않은 것으로 밝혀졌습니다.

"실제로는 아무 것도 하지 않습니다. 수동으로 생성해야 함"을 원하지 않는 경우 요청 시 작업을 생성하는 것을 반환하는 것으로 모델링하는 것이 더 깔끔하다는 것을 알았습니다. 즉 Func<Task> 와 같은 간단한 것입니다.

나는 정반대를 느낀다. JavaScript에 대한 제 경험에 따르면 await를 사용하는 것을 잊는 것은 매우 일반적입니다.

C#은 사용자가 기다리거나 작업을 현명하게 사용했는지 확인하기 위해 작동합니다.

그러나 오류는 삼킬 것입니다

그것은 내가 말하는 것과 반대입니다. 내가 코드를 열심히 실행하여 작업에서 코드를 실행하는 데 끝내지 못하는 경우에도 오류가 즉시 발생하도록 하고 싶습니다. 이것은 반복자와 동일합니다. 반복자가 스트리밍되는 경우 잠재적으로 훨씬 더 아래쪽에 있는 함수와 호출할 때의 시점에서 내가 잘못 생성했다는 것을 훨씬 더 알고 싶습니다.

그런 다음 실행되고 있지 않음을 확인하고 조사하고 수정합니다.

내가 말하는 시나리오에서 "실행하지 않음"은 완전히 합리적입니다. 결국 내 응용 프로그램은 실제로 작업을 실행할 필요가 없다고 결정할 수 있습니다. 그것은 내가 설명하는 버그가 아닙니다. 제가 설명하는 버그는 유효성 검사를 통과하지 못했다는 것입니다. 작업이 실제로 실행되어야 하는 시점이 아니라 논리적으로 작업을 생성한 시점에 가까운 지점에서 이에 대해 알고 싶습니다. 이것이 비동기 처리를 설명하는 모델이라는 점을 감안할 때 서로 멀리 떨어져 있는 경우가 종종 있습니다. 따라서 가능한 한 빨리 문제에 대한 정보를 얻는 것이 중요합니다.

언급했듯이 이것은 가설이 아닙니다. 스트림/반복자에서도 비슷한 일이 발생합니다. 사람들은 종종 그것을 만들지만 나중에야 깨닫습니다. 사람들이 이러한 것들을 소스로 다시 추적해야 하는 것은 추가적인 부담이었습니다. 이것이 바로 많은 API(hte BCL 포함)가 동기/초기 작업과 실제 지연/지연 작업을 분할해야 하는 이유입니다.

그것은 내가 말하는 것과 반대입니다. 내가 코드를 열심히 실행하여 작업에서 코드를 실행하는 데 끝내지 못하는 경우에도 오류가 즉시 발생하도록 하고 싶습니다.

초기 오류에 대한 열망은 이해할 수 있지만 혼란스럽습니다. 어떤 상황에서 " Future 를 생성하지 못하게 될 것"입니까?

Future 가 Rust에서 작동하는 방식은 Future 를 다양한 방식으로 함께 구성하는 것입니다(async/await 포함, 병렬 결합기 등). 모든 하위 Future 를 포함하는 단일 융합 Future . 그런 다음 프로그램의 최상위 수준( main )에서 tokio::run (또는 이와 유사한 것)을 사용하여 생성합니다.

그 외에 하나에서 tokio::run 에서 전화 main , 당신은 일반적으로 산란되지 않습니다 Future 대신 단지를 구성, 수동이야. 그리고 합성은 자연스럽게 생성/오류 처리/취소 등을 처리합니다. 바르게.

나는 또한 뭔가를 분명히하고 싶습니다. 내가 다음과 같이 말할 때 :

그러나 실제로는 그렇게 바람직하지 않은 것으로 밝혀졌습니다.

나는 우리의 언어/플랫폼에 대해 아주 구체적으로 이야기하고 있습니다. C#/.Net/CoreFx 등에 대해 합리적인 결정에 대한 통찰력만 제공할 수 있습니다. 상황이 다르고 최적화하려는 대상과 취해야 하는 접근 유형이 완전히 다른 경우일 수 있습니다. 다른 방향.

나는 초기 오류에 대한 욕구를 이해할 수 있지만 혼란 스럽습니다. 어떤 상황에서 "미래를 생성하지 못하게됩니까"?

항상 :)

Roslyn(C#/VB 컴파일러/IDE 코드베이스) 자체가 어떻게 작성되었는지 고려하십시오. 그것은 매우 비동기적이고 상호작용적 입니다. 즉, 주요 사용 사례는 액세스하는 많은 클라이언트와 공유 방식으로 사용하는 것입니다. 가장 중요한 서비스는 풍부한 기능을 통해 사용자와 일반적으로 상호 작용하며 많은 기능이 사용자가 원하는 수의 작업을 수행하기 때문에 원래 중요하다고 생각했던 작업을 더 이상 수행할 필요가 없다고 결정합니다. 예를 들어, 사용자가 입력할 때 우리는 수많은 작업 구성 및 조작을 수행하고 있으며 몇 ms 후에 다른 이벤트가 발생했기 때문에 실행조차 하지 않기로 결정할 수 있습니다.

예를 들어, 사용자가 입력할 때 우리는 수많은 작업 구성 및 조작을 수행하고 있으며 몇 ms 후에 다른 이벤트가 발생했기 때문에 실행조차 하지 않기로 결정할 수 있습니다.

근데 취소처리만 되는거 아님?

그리고 합성은 자연스럽게 생성/오류 처리/취소 등을 처리합니다. 바르게.

단순히 사물을 나타내는 두 가지 매우 다른 모델이 있는 것처럼 들립니다. 괜찮아요 :) 제 설명은 우리가 선택한 모델의 맥락에서 취해져야 합니다. 선택하는 모델에 맞지 않을 수 있습니다.

단순히 사물을 나타내는 두 가지 매우 다른 모델이 있는 것처럼 들립니다. 괜찮아요 :) 제 설명은 우리가 선택한 모델의 맥락에서 취해져야 합니다. 선택하는 모델에 맞지 않을 수 있습니다.

물론 저는 당신의 관점을 이해하려고 노력하고 있으며 우리의 관점도 설명하고 있습니다. 시간을 내어 설명해 주셔서 감사합니다.

근데 취소처리만 되는거 아님?

취소는 비동기에 대한 직교 개념입니다(저희에게). 일반적으로 함께 사용됩니다. 그러나 어느 쪽도 다른 쪽을 필요로 하지 않습니다.

시스템을 완전히 취소하지 않고 가질 수 있으며 작성한 작업을 '대기'하는 코드를 실행하지 못하는 경우가 있을 수 있습니다. 즉, 논리적인 이유로 코드가 "'t'를 기다릴 필요가 없습니다. 다른 작업을 수행할 것입니다." (우리 세상에서) 작업에 대한 어떤 것도 그 작업이 기다리고 있을 것으로 예상해야 한다고 지시하거나 필요로 하지 않습니다. 그런 시스템에서는 조기 검증을 받고 싶습니다.

참고: 이것은 반복자 문제와 유사합니다. 나중에 코드에서 사용 하려는 결과를 얻기 위해 누군가를 호출할 수 있습니다. 그러나 여러 가지 이유로 결과를 실제로 사용하지 않아도 될 수 있습니다. 내 개인적인 바람은 기술적으로 얻을 수 없고 내 프로그램이 성공하더라도 유효성 검사 결과를 일찍 얻는 것입니다.

나는 두 방향 모두에 대해 합리적인 주장이 있다고 생각합니다. 그러나 내 생각은 동기식 접근 방식이 단점보다 장점이 더 많다는 것입니다. 물론 동기식 접근 방식이 실제 impl이 작동하려는 방식으로 인해 문자 그대로 맞지 않으면 수행해야 하는 작업에 대한 질문에 답하는 것 같습니다. D

다시 말해서, 나는 당신의 접근 방식이 여기에서 나쁘지 않다고 생각합니다. 그리고 이 모델에 대해 강력한 이점이 있다면 Rust에 적합하다고 생각한다면 def로 이동하세요. :)

시스템을 완전히 취소하지 않고 가질 수 있으며 작성한 작업을 '대기'하는 코드를 실행하지 못하는 경우가 있을 수 있습니다. 즉, 논리적인 이유로 코드가 "'t'를 기다릴 필요가 없습니다. 다른 작업을 수행할 것입니다."

개인적으로 저는 이것이 일반적인 if/then/else 논리로 가장 잘 처리된다고 생각합니다.

async fn foo() {
    if some_condition {
        await!(bar());
    }
}

그러나 당신이 말했듯이 C#과 매우 다른 관점입니다.

개인적으로 나는 이것이 일반적인 if/then/else 논리로 가장 잘 처리된다고 생각합니다.

예. 작업이 생성되는 동일한 지점에서 조건 확인을 수행할 수 있다면 괜찮을 것입니다(많은 경우가 이와 같습니다). 그러나 우리 세계에서는 일반적으로 사물이 그렇게 잘 연결되어 있지 않습니다. 결국, 우리는 사용자에 대한 응답으로 비동기 작업을 열심히 수행하고 싶지만(필요할 때 결과가 준비되도록) 나중에 더 이상 신경 쓰지 않는다고 결정할 수 있습니다.

우리 영역에서 '기다림'은 사람이 "값이 필요한" 지점에서 발생하며, 이는 다른 결정/구성요소 등입니다. "가치에 대한 작업을 시작해야 합니까?"에 대한 결정에서

어떤 면에서 이것들은 매우 분리되어 있으며 미덕으로 간주됩니다. 생산자와 소비자는 완전히 다른 정책을 가질 수 있지만 'Task'의 멋진 추상화를 통해 수행 중인 비동기 작업에 대해 효과적으로 의사 소통할 수 있습니다.

어쨌든, 나는 동기화/비동기 의견에서 물러나겠습니다. 분명히 여기에는 매우 다른 모델이 있습니다. :)

우선 순위 측면에서 저는 C#이 사물에 대해 어떻게 생각하는지에 대한 몇 가지 정보를 제공했습니다. 도움이 되기를 바랍니다. 거기에서 더 많은 정보를 원하시면 저에게 알려주십시오.

@CyrusNajmabadi 예, 귀하의 통찰력이 매우 도움이 되었습니다. 개인적으로 나는 await? foo 가 가야 할 길이라는 데 동의합니다(하지만 "명시적인 async " 제안도 마음에 듭니다).

BTW, 모델링 비동기/동기화 작업과 해당 시스템의 모든 장단점에 대한 .net 모델의 모든 복잡성에 대한 최고의 전문가 의견 중 하나를 원하신다면 @stephentoub 가 대화

내 기억으로는 이러한 분할에 대한 비슷한 생각이 초기에 .net의 접근 방식에 반영되었으며, 그가 내린 궁극적인 결정과 그것이 얼마나 적절했는지에 대해 아주 잘 말할 수 있었던 것 같습니다.

조금 낯설더라도 await? future 에 찬성 투표할 것입니다. 그것들을 구성하는 데 실질적인 단점이 있습니까?

다음은 콜드(F#)와 핫(C#, JS) 비동기의 장단점에 대한 또 다른 철저한 분석입니다. http://tomasp.net/blog/async-csharp-differences.aspx

이제 전용 구문 변경 없이 접미사 await 실험할 수 있는 접미사 매크로용 새로운 RFC가 있습니다: https://github.com/rust-lang/rfcs/pull/2442

await {} 는 여기서 내가 가장 좋아하는 것으로 unsafe {} 연상케 하며 우선 순위를 보여줍니다.

let value = await { future }?;

@seunlanlege
예, 연상시키므로 사람들은 다음과 같은 코드를 작성할 수 있다는 잘못된 가정을 합니다.

let value = await {
   let val1 = future1;
   future2(val1)
}

그러나 그들은 할 수 없습니다.

@Pzixel
내가 당신을 올바르게 이해한다면, 당신은 사람들이 await {} 블록 내에서 선물이 암시적으로 기다리고 있다고 가정할 것이라고 가정하고 있습니까? 나는 그것에 동의하지 않습니다. await {} 는 블록이 평가할 표현식에서만 기다립니다.

let value = await {
    let future = create_future();
    future
};

그리고 그것은 낙담하는 패턴이어야합니다

쉽게 한

let value = await { create_future() };

두 개 이상의 표현이 "권장되어야 한다"는 진술을 제안합니다. 당신은 그것에 문제가 있다고 생각하지 않습니까?

await 를 패턴으로 만드는 것이 유리합니까( ref 등 제외)?
다음과 같은 것:

let await n = bar();

나는 그것을 await 보다 async 패턴이라고 부르는 것을 선호하지만, 패턴 구문으로 만드는 이점은 별로 없습니다. 패턴 구문은 일반적으로 해당 표현식과 관련하여 이중으로 작동합니다.

https://doc.rust-lang.org/nightly/std/task/index.html 의 현재 페이지에 따르면 작업 모드는 libcore에서 다시 내보내기와 liballoc에서 다시 내보내기로 구성되어 결과가 약간 ... 차선책. 안정화되기 전에 이 문제가 어떻게든 해결되기를 바랍니다.

코드를 살펴보았습니다. 몇 가지 제안 사항이 있습니다.

• [x] UnsafePoll 트레잇과 Poll 열거형은 이름이 매우 비슷하지만 관련이 없습니다. 나는 이름을 변경하는 것이 좋습니다 UnsafePoll 로, 예를 UnsafeTask .
• [x] 선물 상자에서 코드는 다른 하위 모듈로 분할되었습니다. 이제 대부분의 코드는 task.rs 함께 묶여 탐색하기가 더 어렵습니다. 다시 분할하는 것이 좋습니다.
• [x] TaskObj#from_poll_task() 에 이상한 이름이 있습니다. 이름을 new() 지정하는 것이 좋습니다.
• [x] TaskObj#poll_task 는 poll() 있습니다. 필드라는 poll 를 호출 할 수 poll_fn 또한 함수 포인터의 제안 것이다
• Waker 는 TaskObj 와 동일한 전략을 사용하고 vtable을 스택에 넣을 수 있습니다. 그냥 아이디어입니다. 우리가 이것을 원하는지 모르겠습니다. 간접적인 영향이 조금 더 적기 때문에 더 빠르지 않을까요?
• [ ] dyn 는 이제 베타에서 안정적입니다. 코드는 적용되는 곳에 dyn 사용해야 합니다.

이 물건에 대한 PR도 제공할 수 있습니다. @cramertj @aturon 자세한 내용을 논의하려면 Discord를 통해 저에게 연락해 주세요.

모든 Future 대해 await() 메소드를 추가하는 것은 어떻습니까?

    /// just like and_then method
    let x = f.and_then(....);
    let x = f.await();

    await f?     =>   f()?.await()
    await? f     =>   f().await()?

/// with chain invoke.
let x = first().await().second().await()?.third().await()?
let x = first().await()?.second().await()?.third().await()?
let x = first()?.await()?.second().await()?.third().await()?

@zengsai 문제는 await 가 일반 방법처럼 작동하지 않는다는 것입니다. 사실 async 블록/함수가 아닐 때 await 메서드가 무엇을 하는지 생각해 보십시오. 메소드는 어떤 컨텍스트에서 실행되는지 알지 못하므로 컴파일 오류가 발생하지 않습니다.

@xfix 이것은 일반적으로 사실이 아닙니다. 컴파일러는 원하는 모든 작업을 수행할 수 있으며 이 경우 특별히 메서드 호출을 처리할 수 있습니다. 메서드 스타일 호출은 기본 설정 문제를 해결하지만 예상치 못한(다른 언어에서는 await가 작동하지 않음) 컴파일러에서 추악한 해킹이 될 수 있습니다.

@elszben 컴파일러가 원하는 대로 할 수 있다고 해서 원하는 대로 수행 해야 하는 것은 아닙니다.

future.await() 는 일반 함수 호출처럼 들리지만 그렇지 않습니다. 이런 식으로 가고 싶다면 위에서 제안한 future.await!() 구문이 동일한 의미를 허용하고 매크로로 명확하게 표시할 수 있습니다.

편집: 게시물이 삭제됨

이 게시물을 future RFC로 옮겼습니다. 링크

async fn 와 #[must_use] 사이의 상호 작용을 본 사람이 있습니까?

async fn 경우 이를 직접 호출하면 코드가 실행되지 않고 Future 반환됩니다. 모든 async fn 에는 "외부" impl Future 유형에 고유한 #[must_use] 가 있어야 하므로 Future 무언가를 하지 않고는 호출할 수 없습니다

그 위에, 당신이 경우 첨부합니다 #[must_use] 받는 async fn 즉 내부 함수의 반환에 적용해야처럼 자신이 보인다. 따라서 #[must_use] async fn foo() -> T { ... } 작성하면 await 결과로 무언가를 하지 않고는 await!(foo()) 를 작성할 수 없습니다.

async fn과 #[must_use] 사이의 상호 작용을 본 사람이 있습니까?

이 토론에 관심이 있는 다른 사람들은 https://github.com/rust-lang/rust/issues/51560을 참조

비동기 함수를 구현하는 방법에 대해 생각하고 있었고 이러한 함수가 재귀 또는 상호 재귀를 지원하지 않는다는 것을 깨달았습니다.

await 구문의 경우 저는 개인적으로 사후 수정 매크로를 선호하고 암시적 대기 접근 방식이 없으며 연결이 쉽고 일종의 메서드 호출처럼 사용할 수도 있습니다.

@warlord500 위에서 설명한 수백만 개발자의 전체 await 를 연결하고 싶지 않습니다.

@Pzixel 내가 스레드나 내가 원하는 것을 읽지 않았다고 가정하지 마십시오.
일부 기여자가 연결 대기를 허용하고 싶지 않을 수도 있다는 것을 알고 있지만 우리 중 일부는
하는 개발자. 나는 당신이 내가 무시하고 있다는 개념을 어디서 얻었는지 확실하지 않습니다.
개발자 의견, 내 의견은 커뮤니티 구성원의 의견과 그 의견을 유지하는 이유를 지정했을 뿐입니다.

편집 : 의견이 다르면 공유하십시오! 말하는 이유가 궁금하다
구문과 같은 방법을 통해 연결 대기를 허용해서는 안 됩니까?

@warlord500은 MS 팀이 수천 명의 고객과 수백만 명의 개발자에게 경험을 공유했기 때문입니다. 나는 매일 비동기/대기 코드를 작성하기 때문에 그것을 스스로 알고 있으며, 당신은 그것들을 연결하고 싶지 않습니다. 원하는 경우 정확한 견적은 다음과 같습니다.

우리는 'wait'로 우선순위에 대해 많이 생각했고 원하는 형태를 설정하기 전에 많은 형태를 시도했습니다. 우리가 찾은 핵심 사항 중 하나는 우리와 이 기능을 사용하고자 하는 고객(내부 및 외부)에게 사람들이 비동기 호출 이후에 무엇이든 '연결'하고 싶어하는 경우가 거의 없다는 것입니다. 다시 말해, 사람들은 완전한 표현의 가장 중요한 부분인 '기다림'에 대해 강하게 끌리는 것처럼 보였고 따라서 그것을 정상 가까이에 두는 것 같았습니다. 참고: '전체 표현식'이란 표현식의 맨 위에 있는 표현식이나 최상위 할당 오른쪽에 있는 표현식 또는 '인수'로 전달하는 표현식과 같은 것을 의미합니다.

사람들이 expr 내부에서 'await'로 '계속'하고 싶어하는 경향은 드뭅니다. (await expr).M() 와 같은 것을 가끔 볼 수 있지만 await expr.M() 하는 사람들보다 덜 일반적이고 덜 바람직해 보입니다.

나는 지금 매우 혼란 스럽다. 내가 당신을 올바르게 이해했다면 우리는 지원하지 않아야합니다.
일반적으로 사용되지 않기 때문에 post-fix easy chain 스타일을 기다리십니까? await는 표현식의 가장 중요한 부분으로 간주됩니다.
이 경우에만 귀하를 올바르게 이해하고 있다고 가정합니다.
내가 틀렸다면 주저하지 말고 바로잡아주세요.

또한 견적을 받은 곳의 링크를 게시할 수 있습니다.
감사 해요.

위의 두 가지 요점에 대한 제 반대는 일반적으로 무언가를 사용하지 않기 때문에 반드시 지원하는 것이 코드를 더 깨끗하게 만드는 경우에 해롭다는 의미는 아닙니다.

미래 생성 표현식이 다음과 같은 경우 표현식의 가장 중요한 부분을 inst 대기
가장 중요한 부분이고 맨 위에 놓고 싶은 경우 일반 매크로 스타일 외에 접미사 매크로 스타일을 허용하면 여전히 그렇게 할 수 있습니다.

또한 견적을 받은 곳의 링크를 게시할 수 있습니다.
감사 해요.

하지만... 하지만 당신은 당신이 전체 스레드를 읽었다고 말했습니다... 😃

하지만 공유하는 데 문제가 없습니다: https://github.com/rust-lang/rust/issues/50547#issuecomment -388939886 . 모든 Cyrus 게시물을 읽으실 것을 제안합니다. 이는 실제로 전체 C#/.Net 생태계의 경험이며 Rust에서 재사용할 수 있는 귀중한 경험입니다.

때로는 표현의 가장 중요한 부분을 기다리다

인용문은 분명히 정반대입니다.

async/await에 대한 경험이 있습니까? 그럼 공유 부탁드려도 될까요?

와우, 내가 그것을 놓쳤다는 것이 믿기지 않습니다. 시간을 내어 링크해 주셔서 감사합니다.
나는 경험이 없기 때문에 큰 계획에서 내 의견은 그다지 중요하지 않다고 생각합니다.

@Pzixel async / await 사용하여 귀하와 다른 사람들의 경험에 대한 정보를 공유해 주셔서 감사합니다. 하지만 다른 기여자들을 존중해 주십시오. 자신의 기술적 요점을 듣기 위해 다른 사람의 경험 수준을 비판할 필요가 없습니다.

중재자 참고 사항: @Pzixel 커뮤니티 구성원에 대한 절대 다시 하지마. 중재 정책에 대해 질문이 있는 경우 [email protected] 로

@crabtw 나는 누구를 비판하지 않았습니다. 불편을 끼쳐드려 죄송합니다.

나는 사람이 '기다림'을 실제로 필요로 하는지 이해하고 싶을 때 경험에 대해 물었습니다. 권위에 호소하고 싶지 않았습니다. "직접 시도해보고 이 진실을 스스로 깨달아야 합니다"라고 말할 수 있는 유용한 정보였습니다. 여기에는 공격적인 것이 없습니다.

커뮤니티 회원에 대한 인신공격은 허용되지 않습니다. 님의 댓글에서 수정했습니다.

인신공격은 없습니다. 내가 볼 수 있듯이 당신은 downvotes에 대한 내 참조를 주석 처리했습니다. 글쎄, 그것은 내 게시물 downvote에 대한 내 원자로였습니다. 특별한 것은 없었습니다. 제거되었으므로 해당 참조를 제거하는 것도 합리적이므로(추가 독자에게는 혼란스러울 수 있음) 제거해 주셔서 감사합니다.

참조해주셔서 감사합니다. 나는 당신이 내가 말하는 '복음'을 받아들여서는 안 된다고 언급하고 싶었습니다. :) Rust와 C#은 다른 커뮤니티, 패러다임, 관용구를 가진 다른 언어입니다. 당신은 당신의 언어에 대해 최선의 선택을 해야 합니다. 제 말이 도움이 되고 통찰력을 줄 수 있기를 바랍니다. 하지만 항상 다양한 방식으로 일을 처리할 수 있습니다.

내 희망은 당신이 Rust를 위해 놀라운 것을 생각해내는 것입니다. 그런 다음 우리는 당신이 무슨 짓을했는지 볼 수 있고 기꺼이 C #을 위해 그것을 채택 훔치는 :)

내가 말할 수있는 한, 연결된 인수는 주로 await 의 우선 순위 에 대해 이야기하고 특히 await x.y() 를 await (x.y()) 보다는 (await x).y() 사용자가 전자의 해석을 더 자주 원하고 기대하기 때문에 await!(x.y()) 와 같은 구문이 모호성을 제거한다는 점을 관찰했지만 동의하는 경향이 있습니다.

그러나 x.y().await!().z() 와 같은 연결의 가치와 관련하여 특정 답변을 제안한다고 생각하지 않습니다.

인용된 주석은 부분적으로 흥미롭습니다. Rust에는 최종 await 구문을 파악하는 것을 지연시키는 큰 요인 중 하나인 큰 차이가 있기 때문입니다. C#에는 ? 연산자가 없으므로 다음을 수행하는 코드가 없습니다. (await expr)? 로 작성해야 합니다. 그들은 (await expr).M() 를 정말 드문 것으로 설명하고, 나는 그것이 Rust에서도 사실일 것이라고 생각하는 경향이 있지만, 내 관점에서 유일한 예외는 ? 이며, 이는 매우 일반적입니다. 많은 미래가 결과로 평가될 것이기 때문입니다(예를 들어, 현재 존재하는 모든 선물이 결과로 평가됩니다).

@withoutboats 네 맞습니다. 이 부분을 다시 한 번 인용하고 싶습니다.

내 관점에서 유일한 예외는 ?

유일한 예외가 있다면 그때는 만들 타당 await? foo A의 바로 가기로 (await foo)? 와 두 세계의 최고를 가진.

지금, 최소한의 제안 구문 await!() 의 명확한 사용하실 수 ? . await 대한 기본 구문을 변경하기로 결정한 경우 await 및 ? 조합에 대한 일부 더 짧은 구문에 대해 걱정할 수 있습니다. (그리고 우리가 변경 내용에 따라, 우리는 전혀 문제가되지 않을 수도 있습니다.)

@joshtriplett 이 추가 중괄호는 모호성을 제거하지만 실제로는 매우 무겁습니다. 예: 현재 프로젝트 전체에서 검색:

Matching lines: 139 Matching files: 10 Total files searched: 77

2743 sloc에 139가 있습니다. 별거 아닐 수도 있지만 브레이스가 없는 대안을 더 깨끗하고 더 나은 대안으로 생각해야 한다고 생각합니다. 즉, ? 는 유일한 예외이므로 중괄호 없이 쉽게 await foo 를 사용할 수 있으며 이 특별한 경우에만 특별한 구문을 도입할 수 있습니다. 큰 문제는 아니지만 LISP 프로젝트를 위해 일부 중괄호를 절약할 수 있습니다.

비동기 함수가 서명에 대해 외부 반환 유형 접근 방식을 사용해야 하는 이유에 대한 블로그 게시물을 만들었습니다. 독서를 즐기십시오!

https://github.com/MajorBreakfast/rust-blog/blob/master/posts/2018-06-19-outer-return-type-approach.md

나는 모든 토론을 따르지 않았으므로, 내가 놓쳤다면 이미 논의되었을 위치를 자유롭게 지적해 주십시오.

다음은 내부 반환 유형 접근 방식에 대한 추가 관심사입니다. Stream 구문이 지정될 때 어떻게 생겼을까요? async fn foo() -> impl Stream<Item = T> 은 async fn foo() -> impl Future<Output = T> 와 일치하고 멋지게 보일 것이라고 생각하지만 내부 반환 유형 접근 방식에서는 작동하지 않습니다. 그리고 async_stream 키워드를 도입하고 싶지 않을 것 같습니다.

@Ekleog Stream은 다른 키워드를 사용해야 합니다. impl Trait 는 반대로 작동하기 때문에 async 사용할 수 없습니다. 특정 특성만 구현되도록 할 수 있지만 특성 자체는 기본 구체적인 유형에서 이미 구현되어야 합니다.

그러나 외부 반환 유형 접근 방식은 언젠가 비동기 생성기 함수를 추가하려는 경우에 유용할 것입니다.

async_gen fn foo() -> impl AsyncGenerator<Yield = i32, Return = ()> { yield 1; ... }

Stream 는 Return = () 하여 모든 비동기 생성기에 대해 구현할 수 있습니다. 이를 통해 다음을 수행할 수 있습니다.

async_gen fn foo() -> impl Stream<Item = i32> { yield 1;  ... }

참고: Generator는 이미 nightly에 있지만 이 구문을 사용하지 않습니다. 또한 선물 0.3의 Stream 와 달리 현재 고정 인식 기능이 없습니다.

편집: 이 코드는 이전에 Generator . Stream 와 Generator 의 차이를 놓쳤습니다. 스트림은 비동기식입니다. 이것은 그들이 값을 산출할 수 있지만 반드시 그럴 필요는 없다는 것을 의미합니다. Poll::Ready 또는 Poll::Pending 응답할 수 있습니다. 반면에 Generator 는 항상 동시에 양보하거나 완료해야 합니다. 이를 반영하기 위해 이제 AsyncGenerator 로 변경했습니다.

Edit2: @Ekleog 현재 구현된 제너레이터는 마커가 없는 구문을 사용하며 본문 내부에서 yield 를 찾아 제너레이터여야 함을 감지하는 것 같습니다. 이것은 async 재사용 할 수 있다고 말하는 것이 옳다는 것을 의미합니다. 그러나 그러한 접근 방식이 합리적인지는 또 다른 문제입니다. 하지만 그건 다른 주제를 위한 것 같아요^^'

실제로, 나는 async 재사용할 수 있다고 생각했는데, async 가 이 RFC에 따라 Future s에서만 허용되고 따라서 감지할 수 있기 때문일 것입니다. 그것이 생성하는 것 Stream 반환 형식을 보면 (수 있어야하는 중 하나 Future 또는 Stream ).

우리가 같은 갖고 싶어하기 때문에 지금이 문제를 제기하고있어 이유는 async 생성하는 키워드를 모두 Future s와 Stream 의, 그때 내가 외부 반환 생각 유형 접근 방식은 명시적이기 때문에 훨씬 깨끗할 것이며 async fn foo() -> i32 가 i32 스트림을 생성할 것으로 예상하는 사람은 아무도 없을 것입니다(본문에 yield 및 내부 반환 유형 접근 방식이 선택됨).

제너레이터에 대한 두 번째 키워드(예: gen fn )를 가질 수 있고 둘 다 적용하여 스트림을 생성할 수 있습니다(예: async gen fn ). 외부 반환 유형은 여기에 올 필요가 전혀 없습니다.

@rpjohnst 외부 반환 유형 접근 방식을 사용하면 두 개의 관련 유형을 쉽게 설정할 수 있기 때문에 가져왔습니다.

두 개의 연결된 유형을 설정하고 싶지 않습니다. Stream은 impl Iterator<Item=impl Future>> 또는 이와 유사한 것이 아니라 여전히 단일 유형입니다.

@rpjohnst 연관 유형 Yield 및 Return (비동기) 생성기를 의미했습니다.

gen fn foo() -> impl Generator<Yield = i32, Return = ()> { ... }

이것은 제 원래 스케치였지만 적어도 추적 문제에 대해서는 생성기에 대해 이야기하는 것이 너무 앞서가고 있다고 생각합니다.

// generator
fn foo() -> T yields Y

// generator that implements Iterator
fn foo() yields Y

// async generator
async fn foo() -> T yields Y

// async generator that implements Stream
async fn foo() yields Y

보다 일반적으로 RFC에서 내린 결정을 다시 검토하기 전에 구현에 대해 더 많은 경험이 있어야 한다고 생각합니다. 우리는 이미 했던 것과 같은 주장을 하고 있습니다. 다시 가중치가 필요한지 확인하려면 RFC에서 제안한 기능에 대한 경험이 필요합니다.

귀하의 의견에 전적으로 동의하고 싶지만 궁금한 점이 있습니다. 귀하의 의견을 올바르게 읽으면 async/await 구문의 안정화가 비동기 스트림에 대한 적절한 구문 및 구현을 기다리고 이 두 가지에 대한 경험을 얻을 수 있을까요? (안정화되면 외부 반환 유형과 내부 반환 유형 간에 변경할 수 없기 때문에)

나는 async/await가 Rust 2018에서 예상되고 그때까지 비동기 생성기가 준비되기를 바라지 않을 것이라고 생각했지만…?

(또한 내 의견은 @MajorBreakfast 의 블로그 게시물에 대한 추가 주장으로만 의도되었지만 이 주제에 대한 토론을 완전히 지운 것 같습니다... 그건 내 목표가 아니었고 토론이 다시 초점을 맞춰야 한다고 생각합니다. 이 블로그 게시물?)

await 키워드의 좁은 사용 사례는 여전히 나를 혼란스럽게 합니다. (특히 미래 대 스트림 대 생성기)

모든 사용 사례에 yield 키워드로 충분하지 않습니까? 에서와 같이

{ let a = yield future; println(a) } -> Future

이는 반환 유형을 명시적으로 유지하므로 키워드와 라이브러리를 너무 밀접하게 결합하지 않고 모든 "연속" 기반 의미론에 대해 하나의 키워드만 필요합니다.

(우리는 이것을 클레이 언어로 했습니다 btw)

@aep await 는 생성기에서 미래를 생성하지 않습니다. Future 실행을 일시 중지하고 호출자에게 제어를 반환합니다.

@cramertj 글쎄, 훨씬 더 광범위한 사용 사례인 tho(yield 키워드 뒤에 연속을 포함하는 future를 반환)를 정확히 수행할 수 있었습니다.
하지만 내가 그 토론 파티에 조금 늦었나요? :)

@aep await 특정 키워드에 대한 추론은 미래의 생성기별 yield 키워드와의 조합 가능성을 위한 것입니다. 우리는 비동기 생성기를 지원하기를 원하며 이는 두 개의 독립적인 연속 "범위"를 의미합니다.

또한, Rust 선물은 콜백 기반이 아닌 폴 기반이기 때문에 연속을 포함하는 미래를 반환할 수 없습니다. 적어도 부분적으로는 메모리 관리 이유 때문입니다. poll 가 단일 개체를 변경하는 것이 yield 가 참조를 무시하는 것보다 훨씬 쉽습니다.

async/await는 언어 자체를 오염시키는 키워드 원인이 되어서는 안 된다고 생각합니다. 왜냐하면 async는 언어의 내부가 아닌 기능일 뿐이기 때문입니다.

@sackery 언어 내부의 일부이며 순수하게 라이브러리로 구현할 수 없습니다.

그래서 그냥 nim처럼 키워드로 만드세요, C#은 그렇죠!

질문: 변경 가능한 참조로 값을 캡처하는 async non-move 클로저의 서명은 무엇이어야 합니까? 현재 그들은 완전히 금지되어 있습니다. 클로저 차용이 미래가 죽을 때까지 지속되도록 하는 일종의 GAT 접근 방식을 원하는 것 같습니다. 예:

trait AsyncFnMut {
    type Output<'a>: Future;
    fn call(&'a mut self, args: ...) -> Self::Output<'a>;
}

@cramertj 클로저의 캡처된 환경에 대한 변경 가능한 참조를 반환하는 데 일반적인 문제가 있습니다. 솔루션이 async fn에 연결될 필요가 없을 수도 있습니까?

@withoutboats 맞습니다. 다른 곳보다 async 상황에서 훨씬 더 일반적일 것입니다.

어떻게 약 fn async 대신 async fn ?
같은 I let mut 보다 mut let .

fn foo1() {
}
fn async foo2() {
}
pub fn foo3() {
}
pub fn async foo4() {
}

pub fn 를 검색하면 여전히 소스 코드에서 모든 공개 기능을 찾을 수 있습니다.그러나 현재 구문은 그렇지 않습니다.

fn foo1() {
}
async fn foo2() {
}
pub fn foo3() {
}
pub async fn foo4() {
}

이 제안은 별로 중요하지 않습니다. 개인적인 취향의 문제입니다.
그래서 나는 당신 모두의 의견을 존중합니다 :)

모든 수식어가 fn 앞에 와야 한다고 생각합니다. 다른 언어로 어떻게 되는지 명확합니다. 그냥 상식입니다.

@Pzixel 중요하기 때문에 액세스 수정자가 fn 앞에 와야 한다는 것을 알고 있습니다.
하지만 async 는 아마 아닐 것이라고 생각합니다.

@xmeta 이전에 제안된 이 아이디어를 본 적이 없습니다. 일관성을 위해 async 를 fn 앞에 놓고 싶지만 모든 옵션을 고려하는 것이 중요하다고 생각합니다. 게시해 주셔서 감사합니다!

// Status quo:
pub unsafe async fn foo() {} // #![feature(async_await, futures_api)]
pub const unsafe fn foo2() {} // #![feature(const_fn)]

@MajorBreakfast 이렇게 생각했는데 답변 감사합니다.

{ Public, Private } ⊇ Function  → put `pub` in front of `fn`
{ Public, Private } ⊇ Struct    → put `pub` in front of `struct`
{ Public, Private } ⊇ Trait     → put `pub` in front of `trait`
{ Public, Private } ⊇ Enum      → put `pub` in front of `enum`
Function ⊇ {Async, Sync}        → put `async` in back of `fn`
Variable ⊇ {Mutable, Imutable}  → put `mut` in back of `let`

@xmeta @MajorBreakfast

async fn 는 나눌 수 없으며 비동기 기능을 나타냅니다.。

async fn 는 전체입니다.

pub fn 검색하면 공개 동기화 기능을 검색한다는 의미입니다.
같은 방식으로 pub async fn 검색합니다. 즉, 공개 비동기 기능을 검색한다는 의미입니다.

@ZhangHanDong

• async fn 는 미래를 반환하는 일반 함수를 정의합니다. 미래를 반환하는 모든 함수는 "비동기"로 간주됩니다. async fn 의 함수 포인터와 미래를 반환하는 다른 함수는 동일합니다. 다음은 놀이터의 예 입니다. "async fn"에 대한 검색은 표기법을 사용하는 함수만 찾을 수 있으며 모든 비동기 함수를 찾지는 않습니다.
• pub fn 하면 unsafe 또는 const 기능을 찾을 수 없습니다.

° async fn 의해 반환된 구체적인 유형은 물론 익명입니다. 내 말은 둘 다 Future 를 구현하는 유형을 반환한다는 뜻입니다.

@xmeta 는 mut 가 "let 이후에" 가지 않고, 오히려 mut 가 let 수정하지 않는다는 점에 유의하십시오. let 는 패턴을 취합니다. 즉,

let PATTERN = EXPRESSION;

mut 의 일부인 PATTERN ,하지의 let 자체. 예를 들어:

// one is mutable one is not
let (mut a, b) = (1, 2);

@steveklabnik 이해합니다. 저는 계층 구조와 단어 순서 사이의 연관성을 보여주고 싶었을 뿐입니다. 감사합니다

async 블록 내에서 원하는 return 및 break 행동에 대한 사람들의 생각은? 현재 return 는 비동기 블록에서 반환됩니다. return 를 허용하는 경우 이것이 실제로 가능한 유일한 옵션입니다. 우리는 철저하게 금지 할 수 return 같은 사용 뭔가 'label: async { .... break 'label x; } 비동기 블록에서 돌아갑니다. 이것은 또한 break-to-blocks 기능(https://github.com/rust-lang/rust/issues/)에 키워드 break 또는 return 를 사용할지 여부에 대한 대화와 연결됩니다. 48594).

return 합니다. 이를 금지하는 주요 관심사는 현재 함수에서 반환되지 않고 비동기 블록에서 반환되기 때문에 혼동될 수 있다는 것입니다. 그러나 나는 그것이 혼란스러울 것이라고 의심한다. 폐쇄는 이미 return 허용하고 나는 그것이 혼란스럽다는 것을 결코 발견하지 못했습니다. return 가 비동기 블록에도 적용된다는 것을 배우는 것은 IMO가 쉽고 IMO를 허용하는 것이 매우 중요합니다.

@cramertj return 는 항상 내부 블록이 아니라 포함하는 함수를 종료해야 합니다. 그것이 작동하지 않는 것처럼 들리는 것이 이치에 맞지 않으면 return 가 전혀 작동하지 않아야 합니다.

이를 위해 break 를 사용하는 것은 불행해 보이지만 불행히도 레이블 구분 값이 있다는 점을 감안하면 최소한 그것과 일치합니다.

비동기 이동 및 폐쇄가 아직 계획되어 있습니까? 다음은 RFC에서 가져온 것입니다.

// closure which is evaluated immediately
async move {
     // asynchronous portion of the function
}

그리고 페이지 아래로

async { /* body */ }

// is equivalent to

(async || { /* body */ })()

return 가 클로저와 일치하도록 하고 선택하고 설명하기가 매우 쉽습니다.

break-to-block rfc는 레이블이 있는 내부 클로저에서 뛰어내릴 수 있도록 계획하고 있습니까? 그렇지 않은 경우(그리고 허용해야 한다고 제안하는 것은 아닙니다), returns 의 일관된 동작을 허용하지 않는 것은 매우 불행한 일입니다. 그런 다음 break-to-blocks의 rfc와도 일치하지 않는 대안을 사용합니다.

@memoryruins async || { ... return x; ... } 는 절대적으로 작동해야 합니다. async { ... return x; ... } 는 async 가 클로저가 아니기 때문에 async 가 안됩니다 . return 는 "포함하는 함수에서 반환"이라는 매우 구체적인 의미를 갖습니다. 폐쇄는 기능입니다. 비동기 블록은 그렇지 않습니다.

@memoryruins 둘 다 이미 구현되어 있습니다.

@joshtriplett

비동기 블록은 그렇지 않습니다.

나는 그것들이 그것들을 포함하는 블록에서 별도로 정의된 실행 컨텍스트가 있는 본문이라는 의미에서 그것들을 여전히 함수로 생각한다고 생각합니다. 그래서 return 가 async 블록. 여기서 혼동은 대부분 구문론적으로 보입니다. 블록은 일반적으로 || 및 async 와 같은 새로운 실행 컨텍스트로 코드를 가져오는 것이 아니라 표현식에 대한 래퍼입니다.

@cramertj "구문"은 중요하지만.

이런 식으로 생각하십시오. 함수처럼 보이지 않는 것 (또는 클로저와 비슷하고 클로저를 함수로 인식하는 데 익숙함)이 있고 return 가 표시되는 경우 멘탈 파서는 어디로 가겠습니까?

return 를 가로채는 모든 것은 다른 사람의 코드를 읽는 것을 더 혼란스럽게 만듭니다. 사람들은 적어도 break 가 일부 상위 블록으로 돌아가고 어떤 블록인지 알기 위해 컨텍스트를 읽어야 한다는 아이디어에 익숙합니다. return 는 항상 전체 함수에서 반환되는 더 큰 망치였습니다.

즉시 평가된 클로저와 유사하게 처리되지 않으면 반환이 특히 구문적으로 일관성이 없다는 데 동의합니다. 비동기 블록의 ? 가 이미 결정된 경우(RFC는 여전히 미정이라고 말합니다), 그에 맞춰 정렬될 것이라고 생각합니다.

@joshtriplett 함수와 클로저(구문적으로 매우 다른)를 "반환 범위"로 인식할 수 있지만 비동기 블록은 같은 줄을 따라 인식할 수 없다고 말하는 것이 제게는 임의적입니다. 두 개의 별개의 구문 형식은 허용되지만 3개는 허용되지 않는 이유는 무엇입니까?

RFC에서 이 주제에 대한 사전 논의 가 있었습니다. 내가 거기에서 말했듯이 나는 레이블을 제공할 필요 없이 break _without_ 사용하는 비동기 블록에 찬성합니다(비동기 블록에서 외부 루프로 나갈 방법이 없으므로 표현력을 잃지 않습니다).

@withoutboats 클로저는 또 다른 종류의 기능입니다. "클로저는 함수입니다"를 배우면 " return 항상 포함하는 함수에서 반환"을 포함하여 함수에 대해 알고 있는 모든 것을 클로저에 적용할 수 있습니다.

@Nemo157 레이블이 지정되지 않은 break 대상이 async 블록인 경우에도 비동기 블록 내부의 루프에서 일찍 반환하기 위한 메커니즘(예 'label: async )을 제공해야 합니다. .

@joshtriplett

클로저는 또 다른 종류의 함수일 뿐입니다. "클로저는 함수이다"를 배우면 "반환은 항상 포함하는 함수에서 반환"을 포함하여 함수에 대해 알고 있는 모든 것을 클로저에 적용할 수 있습니다.

async 블록도 일종의 "함수"라고 생각합니다. 즉, 비동기식으로 완료될 때까지 실행할 수 있는 인수가 없습니다. 인수가 없고 미리 적용된 async 클로저의 특수한 경우입니다.

@cramertj 예, 필요한 경우 암시적 중단점에도 레이블을 지정할 수 있다고 가정했습니다(현재 모두 가능하다고 생각함).

제어 흐름을 따르기 어렵게 만드는 모든 것, 특히 return 의미를 재정의하는 것은 코드를 부드럽게 읽는 능력에 상당한 부담을 줍니다.

같은 맥락에서 C의 표준 지침은 "매크로 중간에서 반환되는 매크로를 작성하지 마십시오"입니다. 또는 덜 일반적이지만 여전히 문제가 있는 경우입니다. 루프처럼 보이는 매크로를 작성하면 break 및 continue 가 내부에서 작동해야 합니다. 나는 사람들이 실제로 두 개의 루프를 포함하는 루프 같은 매크로를 작성하는 것을 보았으므로 break 가 예상대로 작동하지 않고 매우 혼란스럽습니다.

비동기 블록도 일종의 "기능"이라고 생각합니다.

구현의 내부를 아는 것에 기반한 관점이라고 생각합니다.

나는 그것들을 전혀 기능으로 보지 않습니다.

나는 그것들을 전혀 기능으로 보지 않습니다.

@joshtriplett

내 의심은 return 가 클로저 내에서 작동하지 않아야 하고 정의 함수 내에서 작동해야 한다는 동일한 주장을 처음으로 클로저가 있는 언어에 적용했을 것이라는 것입니다. 그리고 실제로 Scala와 같이 이 해석을 취하는 언어가 있습니다.

@cramertj 그렇지 않습니다. 함수 내에 정의된 람다 및/또는 함수의 경우 함수라는 것이 완전히 자연스럽습니다. (이에 대한 나의 첫 번째 노출은 Python, FWIW에서 람다가 return 사용할 수 없고 중첩 함수에서 return 는 return 포함하는 함수에서 반환됩니다.)

비동기 블록이 무엇을 하는지 알게 되면 return 가 어떻게 작동해야 하는지 직관적으로 명확해집니다. 이것이 지연된 실행을 나타낸다는 것을 알게 되면 return 가 함수에 적용될 수 없다는 것이 분명해집니다. 블록이 실행될 때 이미 함수가 반환될 것이 분명합니다. IMO에서 이것을 배우는 것은 그다지 어려운 일이 아닙니다. 우리는 적어도 그것을 시도하고 볼 수 있습니다.

이 RFC는 return , break 및 continue 와 같은 ? -operator 및 제어 흐름 구성이 비동기 블록 내에서 작동하는 방식을 제안하지 않습니다.

제어 흐름 연산자를 허용하지 않거나 전용 RFC가 작성될 때까지 블록을 연기하는 것이 가장 좋습니까? 나중에 논의할 다른 원하는 기능이 언급되었습니다. 그 동안 비동기 함수, 클로저 및 await! :)

여기 @memoryruins에 동의합니다. 이러한 세부 사항을 더 자세히 논의하기 위해 또 다른 RFC를 만드는 것이 가치가 있다고 생각합니다.

core::task::context() 라고 하는 비동기 fn 내부에서 컨텍스트에 액세스할 수 있는 함수에 대해 어떻게 생각하십니까? 외부에서 async fn을 호출하면 패닉 상태가 됩니다. 예를 들어 실행 프로그램에 액세스하여 무언가를 생성하는 경우와 같이 매우 편리할 것이라고 생각합니다.

@MajorBreakfast 그 함수는 lazy

async fn foo() -> i32 {
    await!(lazy(|ctx| {
        // do something with ctx
        42
    }))
}

산란과 같은 더 구체적인 것에는 더 인체 공학적으로 만드는 도우미 기능이 있을 것입니다.

async fn foo() -> i32 {
    let some_task = lazy(|_| 5);
    let spawned_task = await!(spawn_with_handle(some_task));
    await!(spawned_task)
}

@Nemo157 실제로 spawn_with_handle 는 이것을 사용하고 싶은 곳입니다. 코드를 0.3으로 변환할 때 spawn_with_handle 는 컨텍스트에 대한 액세스가 필요하기 때문에 실제로는 미래일 뿐입니다( 코드 참조 ). 내가 하고 싶은 것은 spawn_with_handle 메서드를 ContextExt 하고 spawn_with_handle 비동기 함수 내에서만 작동하는 무료 함수로 만드는 것입니다.

fn poll(self: PinMut<Self>, cx: &mut Context) -> Poll<Self::Output> {
     let join_handle = ctx.spawn_with_handle(future);
     ...
}

async fn foo() {
   let join_handle = spawn_with_handle(future); // This would use this function internally
   await!(join_handle);
}

이것은 우리가 현재 가지고 있는 모든 이중 대기 넌센스를 제거할 것입니다.

생각해보면 이 메서드는 core::task::with_current_context() 로 호출되어야 하고 참조를 저장할 수 없어야 하기 때문에 약간 다르게 작동해야 합니다.

편집: 이 함수는 이미 get_task_cx 이름으로 존재합니다 . 현재 기술적인 이유로 libstd에 있습니다. 일단 libcore에 넣을 수 있게 되면 공개 API로 만들 것을 제안합니다.

async 가 아닌 함수에서 호출할 수 있는 함수를 가질 수 있는지 의심스럽습니다. 이 함수는 TLS 외부로 이동된 후 일부 상위 async 함수에서 컨텍스트를 제공할 수 있습니다. 그 시점에서 컨텍스트는 async 함수 내부의 숨겨진 지역 변수처럼 취급될 것이므로 해당 함수에서 컨텍스트에 직접 액세스하는 매크로를 가질 수 있지만 spawn_with_handle 을 가질 방법은 없습니다.

따라서 잠재적으로 다음과 같은

fn spawn_with_handle(executor: &mut Executor, future: impl Future) { ... }

async fn foo() {
    let join_handle = spawn_with_handle(async_context!().executor(), future);
    await!(join_handle);
}

@Nemo157 내 생각에 당신이 옳다고 생각합니다. 내가 제안하는 것과 같은 함수는 async fn 내에서 직접 호출되지 않으면 작동하지 않을 가능성이 큽니다. 아마도 가장 좋은 방법은 spawn_with_handle await 내부적으로 select! 및 join! ).

async fn foo() {
    let join_handle = spawn_with_handle!(future);
    await!(join_handle);
}

이것은 보기에 좋고 매크로 내부의 await!(lazy(|ctx| { ... })) 를 통해 쉽게 구현할 수 있습니다.

async_context!() 는 대기 지점에서 컨텍스트 참조를 저장하는 것을 막을 수 없기 때문에 문제가 됩니다.

async_context!() 는 대기 지점에서 컨텍스트 참조를 저장하는 것을 막을 수 없기 때문에 문제가 됩니다.

구현에 따라 가능합니다. 전체 생성기 인수가 부활하면 어쨌든 양보 지점에서 참조를 유지할 수 없도록 제한되어야 하며, 인수 뒤에 있는 값은 양보 지점까지만 실행되는 수명을 갖습니다. Async/await는 해당 제한을 상속합니다.

@Nemo157 이런 말씀 이신가요?

let my_arg = yield; // my_arg lives until next yield

@Pzixel _아마도 _ 오래된 토론을

예, await!() 구문이 ? 와 같은 것과 결합할 때 모호성을 제거하는 것이 마음에 들지만 이 구문이 단일 프로젝트에서 천 번을 입력하는 것이 짜증난다는 점에도 동의합니다. 또한 시끄럽고 깨끗한 코드가 중요하다고 생각합니다.

그래서 something_async()@ 가 await 와 비교되는 것과 같은 접미사 기호(이전에 몇 번 언급됨)에 ​​대한 실제 인수가 무엇인지 궁금합니다. 아마도 await 때문일 것입니다. @ 는 await의 a 와 비슷하기 때문에 재미있을 수 있지만 잘 어울리는 기호일 수 있습니다.

기본적으로 ? 접미사가 된 try!() 비슷한 일이 발생했기 때문에 이러한 구문 선택이 논리적일 것이라고 주장합니다(정확히 동일하지 않다는 것을 알고 있습니다). 간결하고 기억하기 쉽고 타이핑하기 쉽습니다.

이러한 구문에 대한 또 다른 멋진 점은 ? 기호와 결합할 때 동작이 즉시 명확하다는 것입니다(적어도 그럴 것이라고 믿습니다). 다음을 살펴보십시오.

// Await, then unwrap a Result from the future
awaiting_a_result()@?;

// Unwrap a future from a result, then await
result_with_future()?@;

// The real crazy can make it as funky as they want
magic()?@@?@??@; 
// - I'm joking, of course

await future? 는 이러한 상황에 대해 알지 못하는 한 어떤 일이 일어날지 첫눈에 명확하지 않은 경우에 문제가 되지 않습니다. 그러나 구현은 ? 와 일치합니다.

이제 이 아이디어에 반대할 수 있는 몇 가지 _사소한_ 사항이 있습니다.

• 아마도 await 와 달리 너무 간결하고 덜 눈에 띄거나 장황해서 함수에서 정지 지점을 _어렵게_ 발견할 수 있습니다.
• async 키워드와 비대칭일 수 있습니다. 여기서 하나는 키워드이고 다른 하나는 기호입니다. 그러나 await!() 는 매크로 대 키웨어라는 동일한 문제를 겪고 있습니다.
• 기호를 선택하면 또 다른 구문 요소와 배울 ​​점이 추가됩니다. 그러나 이것이 일반적으로 사용되는 것이 될 수 있다고 가정하면 이것이 문제가 아니라고 생각합니다.

@phaux 는 ~ 기호의 사용도 언급했습니다. 그러나 나는 이 캐릭터가 꽤 많은 키보드 레이아웃에 타이핑하기에는 펑키하다고 생각하므로 그 아이디어를 버리는 것이 좋습니다.

여러분 생각은 어떠세요? try!() _became_ ? 와 비슷하다는 데 동의하십니까? await 또는 기호를 선호하며 그 이유는 무엇입니까? 내가 이것에 대해 토론하는 데 미쳤습니까, 아니면 제가 놓친 것이 있습니까?

제가 사용한 잘못된 용어가 있어서 죄송합니다.

sigil 기반 구문에 대한 가장 큰 걱정은 친절하게 시연한 것처럼 쉽게 글리프 수프로 변할 수 있다는 것입니다. Perl(6 이전 버전)에 익숙한 사람은 이 작업을 수행하는 위치를 이해할 것입니다. 라인 노이즈를 피하는 것이 앞으로 나아가는 가장 좋은 방법입니다.

즉, 가장 좋은 방법은 실제로 try! 와 정확히 같습니다. 즉, 명시적인 async!(foo) 매크로로 시작하고 필요하면 설탕이 될 일부 sigil을 추가하십시오. 물론, 그것은 문제를 나중으로 미루고 있지만 async!(foo) 는 async/await의 첫 번째 반복에 충분하며 상대적으로 논쟁의 여지가 없다는 장점이 있습니다. (그리고 try! / ? 의 선례를 갖는 것은 인장이 있어야 함)

@withoutboats 이 전체 스레드를 읽지 않았지만 구현에 도움을 주는 사람이 있습니까? 개발 지점은 어디입니까?

그리고 나머지 해결되지 않은 고려 사항과 관련하여 Rust 커뮤니티 외부의 전문가에게 도움을 요청한 사람이 있습니까? Joe Duffy 는 동시성에 대해 많은 것을 알고 관심을 갖고 있으며 사소한 세부 사항을 아주 잘 이해하고 있으며 RustConf 에서 에 응할 수 있다고 생각합니다.

@BatmanAoD 초기 구현은 https://github.com/rust-lang/rust/pull/51580 에 착륙했습니다.

원래 RFC 스레드에는 Rust 외부에서도 PLT 분야의 여러 전문가로부터 의견이 있었습니다. :)

나는 시간이 돈이기 때문에 Futures를 기다리는 '$' 기호를 제안하고 싶습니다. 그리고 나는 이것을 컴파일러에게 상기시키고 싶습니다.

농담이야. 기다림의 상징을 갖는 것은 좋은 생각이 아니라고 생각합니다. Rust는 모두 명시적이며 사람들이 자신의 발에 총을 쏘지 않도록 하는 강력한 언어로 낮은 수준의 코드를 작성할 수 있도록 하는 것입니다. 기호는 await! 매크로보다 훨씬 더 모호하며 사람들이 읽기 어려운 코드를 작성하여 다른 방식으로 발에 총을 쏠 수 있습니다. 나는 이미 ? 가 너무 먼 단계라고 주장하고 싶습니다.

나는 또한 async fn 형식으로 사용되는 async 키워드에 동의하지 않습니다. 그것은 비동기에 대한 일종의 "편향"을 의미합니다. 왜 async는 키워드를 받을 자격이 있습니까? 비동기 코드는 항상 필요하지는 않은 또 다른 추상화일 뿐입니다. 나는 async 속성이 더 강력한 코드를 작성할 수 있게 해주는 기본 Rust 방언의 "확장"처럼 작동한다고 생각합니다.

저는 언어 설계자는 아니지만 JavaScript에서 Promises를 사용하여 비동기 코드를 작성한 경험이 있으며 거기에서 수행되는 방식이 비동기 코드를 작성하는 것을 즐겁게 만든다고 생각합니다.

@steveklabnik 아, move 지원이 없는 구현"과 "전체 구현"으로 분할되어야 합니까?

다음 구현 반복이 일부 공개 분기/분기에서 작업되고 있습니까? 아니면 RFC 2418이 승인될 때까지 진행할 수 없습니까?

RFC가 아닌 여기에서 async/await 구문 문제가 논의되는 이유는 무엇입니까?

@c-edw async 키워드에 대한 질문에 대한 답변은 What Color is Your Function?

@parasyte 그 게시물은 사실 자동으로 관리되는 그린 스레드 스타일의 동시성이 없는 비동기 함수에 대한 전체 아이디어에 반대하는 주장이라는 것이 제게 제안되었습니다.

저는 녹색 스레드가 (관리되는) 런타임 없이 투명하게 구현될 수 없고 Rust가 이를 요구하지 않고 비동기 코드를 지원해야 하는 충분한 이유가 있기 때문에 이 입장에 동의하지 않습니다.

하지만 글을 읽으신 분들은 async / await 시맨틱 은 괜찮은데 키워드에 대한 결론은? 확장해 주시겠습니까?

거기에 대한 당신의 견해에도 동의합니다. 나는 async 키워드가 필요하다고 언급했는데 기사에 그 이유가 나와 있습니다. 저자가 내린 결론은 다른 문제입니다.

@parasyte 아, 알았어. 나는 당신이 빨강/파랑 이분법을 싫어하기 때문에 당신이 그 반대를 말하고 있다고 생각했습니다!

내가 정의를 제대로 하지 못했다고 느끼기 때문에 더 명확히 하고 싶습니다.

이분법은 피할 수 없습니다 . 일부 프로젝트에서는 모든 함수 호출을 비동기식으로 만들어 동기화 함수 호출이 존재하지 않도록 하여 지우려고 했습니다. 미도리가 대표적인 예다. 그리고 다른 프로젝트에서는 동기화 기능의 외관 뒤에 비동기 기능을 숨겨 이분법을 지우려고 했습니다. gevent는 이러한 종류의 예입니다.

둘 다 같은 문제가 있습니다. 비동기 작업이 완료되기를 기다리는 것과 작업을 비동기적으로 시작하는 것을 구별하기 위해서는 여전히 이분법이 필요합니다!

• 미도리는 await 키워드 뿐만 아니라 함수 호출 사이트에 async 키워드도 도입 했습니다 .
• gevent는 정상적인 모양의 함수 호출에 대한 암시적 대기 외에 gevent.spawn 를 제공합니다.

이것이 바로 내가 기능별 색상 기사를 가져온 이유입니다. "비동기가 키워드를 사용할 가치가 있는 이유는 무엇입니까?"라는 질문에 대한 답변이기 때문입니다.

글쎄, 쓰레드 기반 동기 코드라도 "작업이 완료되기를 기다리는 것"(조인)과 "작업 시작하기"(스폰)를 구별할 수 있다. 모든 비동기은 (구현 현명)입니다 당신은 언어를 상상할 수 있지만, 아무런 주석이 없다 await (이것은 기본 동작이기 때문에), 미도리의 async 대신 전달 폐쇄입니다 spawn API. 이것은 all-sync와 정확히 동일한 구문/기능-색상 기반에 all-async를 배치합니다.

그래서 나는 async가 키워드를 가질 자격이 있다는 데 동의하지만, Rust가 이 수준에서 구현 메커니즘에 관심을 갖고 있고 그런 이유로 두 가지 색상을 모두 제공해야 하기 때문에 그게 더 많은 것 같습니다.

@rpjohnst 예, 귀하의 제안을 읽었습니다. 색상을 숨기는 것과 개념적으로 동일합니다. 나는 같은 스레드의 녹 포럼에서 비판했습니다. 모든 함수 호출은 동기적으로 보이며 이는 함수가 비동기 파이프라인에서 동기적이고 차단될 때 특히 위험합니다. 이러한 종류의 버그는 예측할 수 없으며 문제를 해결해야 하는 실제 재앙입니다.

내 제안에 대해 특별히 이야기하는 것이 아니라 모든 것이 비동기식인 언어에 대해 이야기하는 것입니다. 그런 식으로 이분법을 벗어날 수 있습니다. 내 제안은 그것을 시도하지 않습니다.

IIUC 그것이 바로 미도리의 시도였다. 그 시점에서 키워드 대 클로저는 의미론적 논쟁에 불과합니다.

2018년 7월 12일 목요일 오후 3시 1분, Russell Johnston [email protected]
썼다:

왜 이분법이 있는지에 대한 논거로 키워드의 존재를 사용했습니다.
아직 미도리에는 존재한다. 그것들을 제거하면 이분법은 어디에 있습니까? 그만큼
구문은 모든 동기화 코드와 동일하지만 async 기능이 있습니다.
암호.

결과를 기다리지 않고 비동기 함수를 호출하면
동기적으로 약속을 반환합니다. 나중에 기다릴 수 있습니다. 😐

_와, 누군가 미도리를 아는 사람이 있습니까? 나는 항상 작업하는 살아있는 생물이 거의 없는 폐쇄형 프로젝트라고 생각했습니다. 여러분 중 누군가가 그것에 대해 더 자세히 써 주면 흥미로울 것입니다._

/주제를 벗어

@Pzixel 프로젝트가 종료되었기 때문에 아직 작업 중인 생물이 없습니다. 그러나 Joe Duffy의 블로그에는 흥미로운 세부 정보가 많이 있습니다. 위의 내 링크를 참조하십시오.

우리는 여기에서 철로를 벗어났고, 제 자신을 되풀이하는 것처럼 느껴지지만 그것은 "키워드의 존재"의 일부인 await 키워드입니다. 키워드를 spawn 및 join spawn 와 같은 API로 바꾸면 Midori와 같이 완전 비동기가 될 수 있지만 (Midori와 달리) 이분법은 없습니다.

다른 말로 하면, 내가 전에 말했듯이, 그것은 기본이 아닙니다. 우리는 선택을 원 하기 때문에 그것을 가질 뿐입니다.

@CyrusNajmabadi 다시 핑을 여기 에 의사 결정에 대한 몇 가지 추가 정보가 있습니다.

다시 언급하고 싶지 않다면 저에게 말씀해 주십시오. 나는 단지 당신이 관심을 가질 수 있다고 생각했습니다.

#wg-net discord 채널에서 :

@cramertj
생각할 거리: 저는 종종 async { ... } 블록의 끝에 Ok::<(), MyErrorType>(()) 를 씁니다. 오류 유형을 더 쉽게 제한할 수 있는 방법이 있습니까?

@withoutboats
[...] 아마도 [ try ]와 일치하기를 원하십니까?

( try 블록이 반환 유형을 선언하는 방법에 대한 비교적 최근의 논의를 기억하지만 지금은 찾을 수 없습니다...)

언급된 색조:

async -> io::Result<()> {
    ...
}

async: io::Result<()> {
    ...
}

async as io::Result<()> {
    ...
}

try 가 async 인체 공학적으로 덜하지만 할 수 있는 한 가지는 변수 바인딩 또는 유형 지정을 사용하는 것입니다. 예:

let _: io::Result<()> = try { ... };
let _: impl Future<Output = io::Result<()>> = async { ... };

나는 이전에 Future 트레잇(예: Future -> io::Result<()> 대해 fn과 같은 구문을 허용하는 아이디어를 던졌습니다. 이렇게 하면 여전히 많은 문자가 있지만 수동 유형 제공 옵션이 좀 더 좋아 보입니다.

let _: impl Future -> io::Result<()> = async {
}

async -> impl Future<Output = io::Result<()>> {
    ...
}

내 선택이 될 것입니다.

기존 클로저 구문 과 유사

|x: i32| -> i32 { x + 1 };

편집: 그리고 결국 TryFuture 가 Future 를 구현하는 것이 가능할 때:

async -> impl TryFuture<Ok = i32, Error = ()> {
    ...
}

Edit2: 정확히 말하면 위의 내용은 오늘날의 특성 정의와 함께 작동합니다. TryFuture 유형은 현재 Future 구현하지 않기 때문에 오늘날 만큼 유용하지 않습니다.

@MajorBreakfast 왜 -> impl Future<Output = io::Result<()>> 아닌 -> io::Result<()> 인가요? 우리는 이미 async fn foo() -> io::Result<()> 대해 return-type-desugaring을 수행하므로 -> 기반 구문을 사용하는 경우 IMO에서 동일한 설탕을 원할 것이 분명해 보입니다.

@cramertj 네, 일관성이 있어야 합니다. 위의 내 게시물은 외부 반환 유형 접근 방식이 우수하다는 것을 모두 확신시킬 수 있다고 가정합니다 😁

async -> R { .. } 를 사용하는 경우 try -> R { .. } 를 사용하고 유형 지정에 일반적으로 expr -> TheType 를 사용해야 합니다. 즉, 우리가 사용하는 유형 지정 구문은 모든 곳에 균일하게 적용되어야 합니다.

@센트릴 공감합니다. 어디서나 사용할 수 있어야 합니다. -> 가 정말 올바른 선택인지 더 이상 확신할 수 없습니다. 나는 -> 를 호출 가능한 것과 연관시킵니다. 그리고 비동기 블록은 그렇지 않습니다.

@MajorBreakfast 기본적으로 동의합니다. 유형 지정에 : 를 사용해야 한다고 생각하므로 async : Type { .. } , try : Type { .. } 및 expr : Type . 우리는 Discord에서 잠재적인 모호성에 대해 논의했으며 의미 있는 : 나아갈 방법을 찾았다고 생각합니다...

또 다른 질문은 Either 열거형에 관한 것입니다. futures 상자에 Either 가 이미 있습니다. 또한 either 상자가 아닐 때 Either 처럼 보이기 때문에 혼란스럽습니다.

Futures std에서 병합된 것처럼 보이기 때문에(적어도 아주 기본적인 부분) 거기에 Either 도 포함할 수 있습니까? 함수에서 impl Future 를 반환할 수 있도록 하는 것이 중요합니다.

예를 들어 저는 종종 다음과 같은 코드를 작성합니다.

fn handler() -> impl Future<Item = (), Error = Bar> + Send {
    someFuture()
        .and_then(|x| {
            if condition(&x) {
                Either::A(anotherFuture(x))
            } else {
                Either::B(future::ok(()))
            }
        })
}

다음과 같이 쓸 수 있기를 바랍니다.

async fn handler() -> Result<(), Bar> {
    let x = await someFuture();
    if condition(&x) {
        await anotherFuture(x);
    }
}

그러나 async 가 확장될 때 Either 가 여기에 삽입되어야 한다는 것을 이해합니다. 왜냐하면 우리는 조건에 들어가거나 그렇지 않기 때문입니다.

_원하는 경우 여기에서 실제 코드를 찾을 수 있습니다.

@Pzixel async 함수 내부에 Either 가 필요하지 않습니다. await 선물을 사용하는 한 async 가 수행하는 코드 변환은 이 두 가지를 숨깁니다. 내부적으로 유형을 지정하고 컴파일러에 단일 반환 유형을 제공합니다.

@Pzixel 또한 https://github.com/rust-lang/rfcs/issues 의 제한된 버전이 도입될 것이기 때문에 (개인적으로) Either 가 이 RFC와 함께 도입되지 않기를 바랍니다. /2414 (이는 2가지 유형에서만 작동하고 Future s에서만 작동함), 따라서 일반 솔루션이 병합되는 경우 API cruft를 추가할 가능성이 있습니다. @Nemo157이 언급했듯이 긴급 상황은 아닌 것 같습니다. 지금 Either 있습니다 :)

@Ekleog 확실히, 저는 기존 비동기 코드에 실제로 수많은 either 가 있다는 이 아이디어에 충격을 받았고 정말로 제거하고 싶습니다. 그런 다음 나는 종속성에 either 크레이트가 있기 때문에 컴파일되지 않는다는 것을 깨달을 때까지 ~30분을 보냈을 때 내 혼란을 회상했습니다(미래의 오류는 이해하기가 매우 어렵기 때문에 꽤 오래 걸렸습니다). 그래서 이 문제가 어떻게든 해결되었는지 확인하기 위해 댓글을 작성했습니다.

물론 이것은 async/await 에만 관련된 것이 아니라 더 일반적인 것이므로 자체 RFC가 필요합니다. 저는 futures 가 either 에 대해 알아야 하거나 그 반대의 경우도 마찬가지임을 강조하고 싶었습니다( IntoFuture 올바르게 구현하기 위해).

@Pzixel 선물 상자에서 내보낸 Either 는 either 상자에서 다시 내보내기한 것입니다. futures 크레이트 0.3은 고아 규칙으로 인해 Either 대해 Future 를 구현할 수 없습니다. 일관성을 위해 Either 대한 Stream 및 Sink impls도 제거하고 대신 대안을 제공할 가능성이 높습니다( 여기에서 설명 ). 또한 either 크레이트는 Future , Stream 및 Sink 자체를 기능 플래그 아래에 구현할 수 있습니다.

즉, @Nemo157이 이미 언급했듯이 선물로 작업할 때 Either 대신 비동기 함수를 사용하는 것이 좋습니다.

async : Type { .. } 은 이제 https://github.com/rust-lang/rfcs/pull/2522 에서 제안됩니다

Send 자동으로 구현하는 비동기/대기 기능이 이미 구현되어 있습니까?

다음 비동기 함수가 (아직?) Send 가 아닌 것 같습니다.

pub async fn __receive() -> ()
{
    let mut chan: futures::channel::mpsc::Receiver<Box<Send + 'static>> = None.unwrap();

    await!(chan.next());
}

전체 재생기( futures-0.3 부족으로 놀이터에서 컴파일되지 않음)에 대한 링크는 여기 입니다.

또한 이 문제를 조사할 때 https://github.com/rust-lang/rust/issues/53249를 찾았습니다. 이 항목을 최상위 게시물의 추적 목록에 추가해야 할 것 같습니다. :)

다음은 Send 구현하는 async/await 함수가 _should_ 작동한다는 것을 보여주는 놀이터 입니다. Rc 버전의 주석 처리를 제거하면 해당 기능이 Send 아닌 것으로 올바르게 감지됩니다. 나는 당신의 구체적인 예를 조금 살펴보고(이 기계에는 Rust 컴파일러가 없습니다 :slightly_frowning_face:) 왜 작동하지 않는지 알아낼 수 있습니다.

@Ekleog std::mpsc::Receiver 은 Sync std::mpsc::Receiver 가 아니며 작성한 async fn 에는 이에 대한 참조가 있습니다. !Sync 항목에 대한 참조는 !Send 입니다.

@cramertj 흠... 하지만, 제네릭 유형이 Send 인 경우 Send 여야 하는 소유 mpsc::Receiver 보유하고 있지 않습니까? (또한 std::mpsc::Receiver 아니라 futures::channel::mpsc::Receiver . type이 Send 인 경우에도 Sync . mpsc::Receiver 알아차리지 못해서 죄송합니다.

@Nemo157 감사합니다! 이 문제에 대한 너무 많은 소음을 피하기 위해 https://github.com/rust-lang/rust/issues/53259를 열었습니다. :)

async 블록이 ? 및 기타 제어 흐름을 허용하는지 여부와 방법에 대한 질문은 try 블록과의 일부 상호 작용을 보증할 수 있습니다(예: try async { .. } 를 허용하려면 ? return 와 유사한 혼동 없이 ?).

이것은 async 블록의 유형을 지정하는 메커니즘이 try 블록의 유형을 지정하는 메커니즘과 상호 작용해야 할 수도 있음을 의미합니다. ascription 구문 RFC에 대한 의견을 남겼습니다. https://github.com/rust-lang/rfcs/pull/2522#issuecomment -412577175

처음에는 futures-rs 문제라고 생각했지만 실제로는 비동기/대기 문제일 수 있으므로 여기를 참조하세요 .

하나의 새로운 문제: https://github.com/rust-lang/rust/issues/53447

며칠 전 discord에서 논의한 바와 같이 await 는 아직 키워드로 예약되지 않았습니다. 2018 릴리스 전에 이 예약을 2018 에디션 키워드 lint에 추가하는 것이 매우 중요합니다. 지금은 매크로 구문을 계속 사용하고 싶기 때문에 예약이 약간 복잡합니다.

Future/Task API에 로컬 future를 생성하는 방법이 있습니까?
SpawnLocalObjError 가 있는 것을 보았지만 사용하지 않은 것 같습니다.

@panicbit 작업 그룹에서 현재 컨텍스트에 생성 기능을 포함하는 것이 타당한지 논의하고 있습니다. https://github.com/rust-lang-nursery/wg-net/issues/56

( SpawnLocalObjError 은 완전히 사용되지는 않습니다: LocalPool of the futures crate가 그것을 사용합니다. 그러나 libcore의 어떤 것도 그것을 사용하지 않는다는 것은 맞습니다)

@withoutboats 문제 설명에 있는 몇 가지 링크가 https://github.com/rust-lang/rfcs/pull/2418 이 닫히고 https://github.com/rust-lang-nursery/futures-rs/issues/1199 가 . /github.com/rust-lang/rust/issues/53548

주의 이 추적 문제의 이름은 async/await이지만 작업 API에도 할당됩니다! 작업 API에는 현재 안정화 RFC가 보류 중입니다. https://github.com/rust-lang/rfcs/pull/2592

대체 비동기 구현을 위해 키워드를 재사용할 수 있는 기회가 있습니까? 현재는 Future를 생성하지만 푸시 기반 비동기를 더 유용하게 만들 기회를 놓친 것입니다.

@aep oneshot::channel 를 사용하여 푸시 기반 시스템에서 풀 기반 Future 시스템으로 쉽게 변환할 수 있습니다.

예를 들어 JavaScript Promises는 푸시 기반이므로 stdweb 은 oneshot::channel 를 사용하여 JavaScript Promises를 Rust Futures로 변환 합니다. 또한 oneshot::channel 와 같은 다른 푸시 기반 콜백 API에 setTimeout 합니다.

Rust의 메모리 모델 때문에 push 기반 Futures는 pull에 비해 추가 성능 비용이 있습니다 . 따라서 전체 Future 시스템을 푸시 기반으로 하는 것보다 필요할 때만 성능 비용을 지불하는 것이 좋습니다(예: oneshot::channel ).

그렇긴 하지만, 저는 코어 팀이나 랭 팀의 일원이 아니므로 제가 말하는 어떤 것도 권위가 없습니다. 제 개인적인 생각일 뿐입니다.

리소스가 제한된 코드에서는 실제로 그 반대입니다. pull 모델은 대기 함수 스택을 통해 다음 준비 값을 제공하는 대신 끌어오는 것 내부에 리소스가 필요하기 때문에 패널티가 있습니다. future.rs 디자인은 네트워크 스위치(내 사용 사례) 또는 게임 렌더러와 같이 하드웨어에 가까운 모든 것에 너무 비쌉니다.

그러나 이 경우에 여기서 필요한 것은 Generator가 하는 것과 같은 비동기를 내보내는 것뿐입니다. 이전에 말했듯이 두 개의 키워드를 단일 라이브러리에 바인딩하는 대신 충분히 추상화하면 비동기 및 생성기가 실제로 동일한 것이라고 생각합니다.

그러나 이 경우에 여기서 필요한 것은 Generator가 하는 것과 같은 비동기를 내보내는 것뿐입니다.

이 시점에서 async 는 말 그대로 제너레이터 리터럴을 둘러싼 최소 래퍼입니다. 제너레이터가 푸시 기반 비동기 IO를 어떻게 지원하는지 확인하는 데 어려움을 겪고 있습니다. 오히려 CPS 변환이 필요하지 않습니까?

"끌어내고 있는 것 내부에 리소스가 필요합니다"라는 말의 의미에 대해 좀 더 구체적으로 말씀해 주시겠습니까? 왜 그것이 필요한지 또는 "대기 중인 함수 스택을 통해 다음 준비 값을 제공하는 것"이 poll() 와 어떻게 다른지 잘 모르겠습니다.

푸시 기반 선물이 더 비싸다는 인상을 받았습니다(따라서 제한된 환경에서 사용하기 더 어렵습니다). 임의의 콜백이 future에 연결되도록 허용하려면 일종의 간접 참조, 일반적으로 힙 할당이 필요하므로 루트 future에 한 번 할당하는 대신 모든 결합자에서 할당합니다. 또한 스레드 안전 문제로 인해 취소가 더 복잡해지기 때문에 이를 지원하지 않거나 경주를 피하기 위해 원자적 연산을 사용하기 위해 모든 콜백 완료가 필요합니다. 이 모든 것이 내가 말할 수 있는 한 프레임워크를 최적화하기가 훨씬 더 어렵습니다.

오히려 CPS 변환이 필요하지 않습니까?

예, 현재 생성기 구문은 연속에 대한 인수가 없기 때문에 작동하지 않습니다. 이것이 비동기가 그것을 수행하는 방법을 가져올 것이라고 기대한 이유입니다.

당기는 것 내부에 리소스가 필요합니까?

그것은 비동기식 작동 순서를 두 번 뒤집는 데 비용이 든다고 말하는 끔찍한 방법입니다. 즉, 하드웨어에서 선물로 한 번, 채널을 사용하여 다시 돌아옵니다. 하드웨어에 가까운 코드에서는 이점이 전혀 없는 많은 것들을 가지고 다녀야 합니다.

일반적인 예는 소켓의 파일 디스크립터가 준비되었음을 알 때 퓨처 스택을 호출할 수 없지만 대신 잠금과 같은 외부 비용이 있는 퓨처에 실제 이벤트를 매핑하기 위해 모든 실행 로직을 구현해야 하는 것입니다. 코드 크기와 가장 중요한 코드 복잡성.

임의의 콜백이 미래에 연결되도록 허용하려면 일종의 간접 참조가 필요합니다.

예, 일부 환경에서는 콜백이 비싸다는 것을 이해합니다(실행 속도와 관련이 없는 내 환경은 아니지만 총 메모리가 1MB이므로 futures.rs는 플래시에도 맞지 않음). 그러나 다음을 수행할 때 동적 디스패치가 필요하지 않습니다. 연속(현재 생성기 개념의 절반 구현)과 같은 것입니다.

또한 스레드 안전성으로 인해 취소가 더 복잡해집니다.

나는 우리가 여기에서 혼란을 겪고 있다고 생각합니다. 저는 콜백을 옹호하는 것이 아닙니다. 연속은 정적 스택이 될 수 있습니다. 예를 들어 우리가 클레이 언어로 구현한 것은 푸시 또는 풀에 사용할 수 있는 생성기 패턴일 뿐입니다. 즉:

async fn add (a: u32) -> u32 {
    let b = await
    a + b
}

add(3).continue(2) == 5

매크로로 계속 할 수 있을 것 같지만, 여기서 하나의 특정 개념에 언어 키워드를 낭비하는 것은 기회를 놓친 것 같습니다.

실행 속도가 중요하지 않은 광산에는 없지만 총 메모리가 1MB이므로 future.rs는 플래시에도 맞지 않습니다.

나는 현재의 미래가 메모리가 제한된 환경에서 실행되도록 의도되었다고 확신합니다. 정확히 무엇이 그렇게 많은 공간을 차지합니까?

편집: 이 프로그램은 내 맥북에서 --release를 컴파일할 때 295KB 디스크 공간을 차지합니다(기본 hello world는 273KB 차지).

use futures::{executor::LocalPool, future};

fn main() {
    let mut pool = LocalPool::new();
    let hello = pool.run_until(future::ready("Hello, world!"));
    println!("{}", hello);
}

실행 속도가 중요하지 않은 광산에는 없지만 총 메모리가 1MB이므로 future.rs는 플래시에도 맞지 않습니다.

나는 현재의 미래가 메모리가 제한된 환경에서 실행되도록 의도되었다고 확신합니다. 정확히 무엇이 그렇게 많은 공간을 차지합니까?

또한 기억이란 무엇을 의미합니까? 128kB 플래시/16kB 램이 있는 장치에서 현재 비동기/대기 기반 코드를 실행했습니다. 현재 async/await에는 확실히 메모리 사용 문제가 있지만 이는 대부분 구현 문제이며 몇 가지 추가 최적화를 추가하여 개선할 수 있습니다(예: https://github.com/rust-lang/rust/issues/52924).

일반적인 예는 소켓의 파일 디스크립터가 준비되었음을 알 때 퓨처 스택을 호출할 수 없지만 대신 잠금과 같은 외부 비용이 있는 퓨처에 실제 이벤트를 매핑하기 위해 모든 실행 로직을 구현해야 하는 것입니다. 코드 크기와 가장 중요한 코드 복잡성.

왜요? 이것은 여전히 ​​미래가 당신을 강요하는 것처럼 보이지 않습니다. 푸시 기반 메커니즘처럼 쉽게 poll 를 호출할 수 있습니다.

또한 기억이란 무엇을 의미합니까?

나는 이것이 관련이 없다고 생각합니다. 이 전체 토론은 내가 의도하지 않은 요점을 무효화하는 것에 대해 자세히 설명했습니다. 나는 미래의 디자인을 핵심 언어에 집어넣는 것이 실수라고 말하는 것 이상을 비판하기 위해 여기에 있는 것이 아닙니다.

제 요점은 async 키워드가 제대로 수행된다면 미래에 대비할 수 있다는 것입니다. 내가 원하는 것은 연속이지만 다른 사람들이 더 나은 아이디어를 생각해 낼 수도 있습니다.

푸시 기반 메커니즘처럼 쉽게 poll을 호출할 수 있습니다.

예, Future:poll 에 호출 인수가 있으면 의미가 있습니다. 설문 조사는 추상적이어야 하기 때문에 가질 수 없습니다. 대신 async 키워드에서 연속을 내보내고 인수가 0인 Continuation에 대해 Future를 impl 제안합니다.

이는 미래에 비용을 추가하지 않지만 현재 한 라이브러리에만 사용되는 키워드의 재사용을 허용하는 간단하고 노력이 적게 드는 변경입니다.

그러나 continations는 물론 전처리기로 구현할 수도 있습니다. 이것이 우리가 할 일입니다. 불행히도 desugar는 적절한 연속보다 비용이 많이 드는 폐쇄일 수 있습니다.

@aep 키워드( async 및 await )를 재사용하려면 어떻게 해야 합니까?

@Centril 내 순진한 빠른 수정은 비동기를 Future가 아닌 Generator로 낮추는 것입니다. 그렇게 하면 생성기가 미래를 위한 독점적인 백엔드가 되기보다는 적절한 연속성을 위해 유용하게 만들 시간이 될 것입니다.

10줄 PR과 비슷합니다. 그러나 나는 그것에 대해 벌집과 싸울 인내심이 없기 때문에 다른 키워드의 설탕을 제거하기 위한 사전 절차를 구축할 것입니다.

나는 비동기 항목을 따르지 않았으므로 이것이 전에 / 다른 곳에서 논의 된 경우 사과하지만 no_std 에서 async / await를 지원하기위한 (구현) 계획은 무엇입니까?

AFAICT 현재 구현은 TLS를 사용하여 Waker를 전달하지만 no_std / core 에는 TLS(또는 스레드) 지원이 없습니다. @alexcrichton 으로부터 Generator.resume 가 인수에 대한 지원을 얻는 경우 TLS를 제거할 수 있다고 들었습니다.

no_std 지원이 구현될 때 async/await의 안정화를 차단할 계획이 있습니까? 아니면 std async / await on stable을 출시하도록 안정화될 부분을 변경하지 않고 no_std 지원을 추가할 수 있다고 확신합니까?

@japaric poll 이제 컨텍스트를 명시적으로 사용합니다. AFAIK, TLS는 더 이상 필요하지 않습니다.

https://doc.rust-lang.org/nightly/std/future/trait.Future.html#tymethod.poll

편집: async/await에는 관련이 없으며 미래에만 해당됩니다.

[...] std async / await on stable을 배송하도록 안정화될 부분을 변경하지 않고 no_std 지원을 추가할 수 있다고 확신합니까?

나는 그렇게 믿는다. 관련 부분은 std::future 의 기능입니다. 이들은 모두 안정화되지 않을 추가 gen_future 불안정한 기능 뒤에 숨겨져 있습니다. async 변환은 set_task_waker 를 사용하여 깨우기를 TLS에 저장하고 await! 는 poll_with_tls_waker 를 사용하여 액세스합니다. 제너레이터가 재개 인수 지원을 받으면 대신 async 변환이 깨우기를 재개 인수로 전달할 수 있고 await! 는 인수에서 이를 읽을 수 있습니다.

편집: 제너레이터 인수가 없어도 비동기 변환에서 약간 더 복잡한 코드로 이 작업을 수행할 수도 있다고 생각합니다. 개인적으로 다른 사용 사례에 대해 추가된 생성기 인수를 보고 싶지만 TLS 요구 사항을 포함하거나 포함하지 않고 제거하는 것이 가능할 것이라고 확신합니다.

@japaric 같은 배. 누군가가 임베디드에서 미래 작업을 했다고 해도 모두 Tier3이기 때문에 매우 위험합니다.

async: weave in the Arc를 수정하는 것보다 훨씬 적은 작업이 필요한 추악한 해킹을 알아냈습니다.제너레이터 스택을 통해

1. "Poll"인수 참조 https://github.com/aep/osaka/blob/master/osaka-dns/src/lib.rs#L76 Arc
2. 87번 라인에서 투표에 무언가 등록하기
3. 줄 92에서 연속점을 생성하기 위해 yield
4. 생성기에서 생성기를 호출하여 라인 207에서 더 높은 수준의 스택을 생성합니다.
5. 마지막으로 215행에서 ​​런타임을 전달하여 전체 스택을 실행합니다.

이상적으로는 Future가 아닌 "순수한" 클로저 스택으로 비동기를 낮추므로 런타임 가정이 필요하지 않으며 순수하지 않은 환경을 루트의 인수로 푸시할 수 있습니다.

나는 그것을 구현하는 데 절반이었습니다.

https://twitter.com/arvidep/status/1067383652206690307

하지만 내가 원하는 유일한 사람이라면 끝까지 가는 것은 무의미합니다.

그리고 제너레이터 인자가 없는 TLS-less async/await가 가능한지 생각을 멈출 수가 없어서 no_std proc-macro 기반 async_block! / await! 매크로 쌍을 구현했습니다. 지역 변수만 사용합니다.

현재의 TLS 기반 솔루션이나 생성기 인수 기반 솔루션(적어도 기본 생성기 인수가 건전하다고 가정할 때)보다 훨씬 더 미묘한 안전 보장이 필요하지만 건전하다고 확신합니다(아무도 없는 한 내가 방법을 찾을 수 없는 다소 큰 위생 구멍을 사용합니다. 이것은 이름을 지정할 수 없는 gensym idents를 사용하여 비동기 변환과 await 매크로 사이에서 통신할 수 있기 때문에 컴파일러 내 구현에서는 문제가 되지 않습니다.

OP에서 await! 을 std 에서 core 로 이동하는 것에 대한 언급이 없다는 것을 방금 깨달았습니다. 아마도 #56767이 추적 안정화 전에 해결해야 할 문제 목록에 추가될 수 있습니다. 이것.

@Nemo157 await! 가 안정화 될 것으로 예상되지 않으므로 어쨌든 차단기가 아닙니다.

@Centril 누가 await! 이 안정화되지 않을 것이라고 말했는지 모르겠습니다... :wink:

@cramertj 그는 내가 믿는 키워드 버전이 아닌 매크로 버전을 의미했습니다 ...

@crlf0710 암시적 대기/명시적 비동기 블록 버전은 무엇입니까?

@crlf0710 저도 그랬어요 :)

@cramertj 현재 await 및 await! 둘 다의 존재를 가능하게 하는 추악한 해킹이 컴파일러에 있기 때문에 매크로를 제거하고 싶지 않습니까? 매크로를 안정화하면 절대 제거할 수 없습니다.

@stjepang 저는 접미사 표기법에 대한 일반적인 선호도와 모호성 및 발음할 수 없는/Google에서 사용할 수 없는 기호를 싫어한다는 점을 제외하고는 await! 의 구문에 대해 어떤 방향으로도 그다지 신경 쓰지 않습니다. 내가 아는 한 현재 제안(우선 순위를 명확히 하기 위해 ? )은 다음과 같습니다.

• await!(x)? (오늘 우리가 가진 것)
• await x? ( await 는 ? 보다 더 단단하게 바인드하고, 여전히 접두사 표기법, 체인 메서드에 괄호가 필요함)
• await {x}? (위와 동일하지만 명확성을 위해 일시적으로 {} 필요)
• await? x ( await 덜 단단히 묶고, 여전히 접두사 표기법, 체인 메서드에 괄호가 필요함)
• x.await? (필드 액세스처럼 보입니다)
• x# / x~ /etc. (일부 상징)
• x.await!()? (접미사 매크로 스타일, @withoutboats 그리고 다른 사람들은 접미사 매크로가 아닌 유형 기반 파견을 허용하기 위해 . 를 기대하기 때문에 아마 다른 사람들은 접미사 매크로 팬이 아니라고 생각합니다. )

배송하는 가장 좋은 방법은 await!(x) , un-keyword-ify await , 결국 언젠가는 x.await!() 를 추가할 수 있는 후위 매크로의 장점으로 사람들을 판매하는 것입니다.

나는 이 문제를 아주 느슨하게 따르지만, 제 의견은 다음과 같습니다.

개인적으로 나는 await! 매크로를 있는 그대로 그리고 여기에 설명된 대로 좋아합니다: https://blag.nemo157.com/2018/12/09/inside-rusts-async-transform.html

어떤 종류의 마법이나 새로운 구문이 아니라 일반 매크로입니다. 더 적은 것이 더 많습니다.

그런 다음 Try 아직 안정화되지 않았기 때문에 try! 도 선호했습니다. 그러나 await!(x)? 는 설탕과 명백한 명명된 작업 사이의 적절한 절충안이며 잘 작동한다고 생각합니다. 또한 디버그 추적과 같은 추가 기능을 처리하기 위해 타사 라이브러리의 다른 매크로로 대체될 수 있습니다.

한편 async / yield 는 생성기에 대한 "그냥" 구문 설탕입니다. JavaScript가 async/await 지원을 받고 있었고 기본적으로 우리가 하는 것처럼 생성기와 Promises/Futures를 비동기 작업에 사용하도록 비동기 코드를 트랜스파일한 Babel 및 Regenerator 와 같은 프로젝트가 있었던 시절이 생각납니다.

결국 우리는 비동기 및 생성기가 별개의 기능이 되기를 원할 것이며 잠재적으로 서로 구성할 수도 있습니다( Stream ). await! 를 yield 로 낮추는 매크로로 남겨두는 것은 영구적인 해결책이 아닙니다.

기다려! 수율을 낮추는 매크로는 영구적인 솔루션이 아닙니다.

yield 낮추는 것이 영구적으로 사용자에게 표시될 수는 없지만 확실히 그런 방식으로 계속 구현될 수 있습니다. async + generators = Stream 있는 경우에도 yield Poll::Pending; 대 yield Poll::Ready(next_value) 와 같이 계속 사용할 수 있습니다.

결국 우리는 비동기 및 생성기가 별개의 기능이 되기를 원할 것임을 명심하십시오.

비동기와 생성기 는 별개의 기능이 아닙니까? 물론 관련이 있지만 이것을 JavaScript가 수행한 방식과 다시 비교하면서 저는 항상 비동기가 생성기 위에 구축될 것이라고 생각했습니다. 비동기 함수의 유일한 차이점은 일반 값과 ​​반대로 Future 반환하고 산출한다는 것입니다. 실행자는 비동기 함수가 실행될 때까지 평가하고 대기해야 합니다. 게다가 내가 확신할 수 없는 몇 가지 추가 평생 물건.

사실, 나는 한 번 이 정확한 것에 대한 라이브러리 를

@cramertj 두 가지가 별개의 "효과"라면 그런 식으로 구현할 수 없습니다. 이에 대한 논의가 있습니다: https://internals.rust-lang.org/t/pre-rfc-await-generators-directly/7202. 우리는 yield Poll::Ready(next_value) 를 원하지 않고 yield next_value 를 원하고 동일한 함수의 다른 곳에 await 갖습니다.

@rpjohnst

우리는 Poll::Ready(next_value)를 산출하고 싶지 않고 next_value를 산출하고 동일한 함수의 다른 곳에서 await를 갖기를 원합니다.

네, 물론 사용자에게 그렇게 보일 것입니다. 하지만 디슈가링의 관점에서 보면 yield 를 Poll::Ready 로 감싸고 Poll::Pending 를 추가해야 합니다. yield 생성된 await! . 최종 사용자에게는 구문상 별도의 기능으로 나타나지만 컴파일러에서 구현을 공유할 수 있습니다.

@cramertj 또한 이것:

• await? x

@novacrazy 예, 별개의 기능이지만 함께 구성 할 수 있어야 합니다.

그리고 실제로 JavaScript 에서는 구성 가능합니다.

https://thenewstack.io/whats-coming-up-in-javascript-2018-async-generators-better-regex/

"비동기 생성기와 반복기는 비동기 함수와 반복기를 결합할 때 얻을 수 있는 것이므로 대기할 수 있는 비동기 생성기 또는 생성할 수 있는 비동기 함수와 같습니다."라고 그는 설명했습니다. 이전에는 ECMAScript를 사용하여 양보하거나 기다릴 수 있지만 둘 다 할 수는 없는 함수를 작성할 수 있었습니다. "이는 특히 스트림을 노출하는 Fetch 개체를 사용하여 웹 플랫폼의 일부가 되고 있는 스트림을 소비하는 데 정말 편리합니다."

async iterator는 Observable 패턴과 비슷하지만 더 유연합니다. “Observable은 푸시 모델입니다. 일단 구독하면 준비 여부에 관계없이 최고 속도로 이벤트와 알림을 받게 되므로 채팅을 처리하기 위해 버퍼링 또는 샘플링 전략을 구현해야 합니다.”라고 Terlson이 설명했습니다. async iterator는 push-pull 모델입니다. 값을 요청하면 값이 전송됩니다. 이는 네트워크 IO 기본 형식과 같은 작업에 더 적합합니다.

@Centril ok, 열림 #56974, OP에 미해결 질문으로 추가될 만큼 정확합니까?

await 구문으로 다시 가고 싶지는 않지만 적어도 한 가지 사항에 응답해야 합니다.

개인적으로 나는 await! 매크로를 있는 그대로 그리고 여기에 설명된 대로 좋아합니다: https://blag.nemo157.com/2018/12/09/inside-rusts-async-transform.html

또한 매크로가 라이브러리에서 구현된 매크로로 유지될 수 있다고 생각하지 않는다고 말했습니다(사용자에게 계속 매크로로 표시되는지 여부는 무시). 이유를 확장하면 다음과 같습니다.

1. 해결되지 않은 문제 중 하나에 따르면 현재 || await!() 를 사용하여 생성기를 만들 수 있다고 말하면서 기본 구현을 숨깁니다.
2. @cramertj이 언급으로, 발전기 비동기 지원하면 구별이 필요한 yield 의 추가 await 다른 yield 의 사용자에 의해 작성된. 이것은 사전 매크로 확장 단계로 수행될 수 _가능합니다. _if_ 사용자는 매크로 내부에서 yield 원하지 않았지만 yield_from! 와 같은 매크로 내부 구조에는 매우 유용한 yield . . 매크로에서 yield 가 지원되어야 한다는 제약 조건으로 인해 await! 는 최소한 내장 매크로가 되어야 합니다(실제 구문이 아닌 경우).
3. async fn 에서 no_std 나는 이것을 구현하는 두 가지 방법을 알고 있습니다. 두 가지 방법 모두 async fn -created- Future 및 await 가 필요하므로 깨우기가 저장된 식별자를 공유해야 합니다. 둘 다 컴파일러에서 구현되는 경우 이 두 위치 간에 위생적으로 안전한 식별자를 공유할 수 있습니다.

여기에 약간의 혼란이 있다고 생각합니다. yield 호출 주변의 래퍼로 await! 를 공개적으로 가시적으로 확장할 수 있는 의도는 결코 아닙니다. await! 매크로와 같은 구문의 미래는 현재 컴파일러 지원 compile_error! , assert! , format_args! 등과 다르지 않은 구현에 의존합니다. 컨텍스트에 따라 다른 코드로 디슈거할 수 있습니다.

여기서 이해해야 할 유일한 중요한 부분은 제안된 구문 간에 의미 있는 의미 차이가 없다는 것입니다. 이는 단지 표면 구문일 뿐입니다.

await 구문을 해결하는 대안을 작성하겠습니다.

우선 await 를 후위 연산자로 넣는 아이디어가 마음에 듭니다. 그러나 expression.await 는 이미 지적했듯이 필드와 너무 비슷합니다.

그래서 제 제안은 expression awaited 입니다. 여기서 단점은 awaited 가 아직 키워드로 유지되지 않지만 영어에서는 더 자연스러우면서도 그런 표현은 없습니다( expression [token] 와 같은 문법 형식)는 Rust에서 유효합니다. 바로 지금, 이것이 정당화될 수 있습니다.

그럼 우리가 쓸 수 expression? awaited 기다리기 위해 Result<Future,_> , 그리고 expression awaited? 대기하는 Future<Item=Result<_,_>> .

@earthengine

나는 awaited 키워드에 매진되지 않았지만 당신은 뭔가에 빠져 있다고 생각합니다.

여기서 핵심 통찰력은 다음과 같습니다. yield 및 await 는 return 및 ? .

return x 반환 가치 x 하면서, x? 랩 해제의 원인이 x 가 있다면 조기 반환 Err .
yield x 수익률은 가치 x , 동안 x awaited 기다리고 미래 x , 그것의 경우 조기 반환 Pending .

거기에 멋진 대칭이 있습니다. 아마도 await 실제로 후위 연산자여야 합니다.

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

나는 @cramertj가 방금 보여준 정확한 이유 때문에 await! / await 와 같은 중첩 의미가 없습니다. ? 의 단순함이 없고 후위 연산자에 사용할 기호가 부족합니다...

개인적으로, 나는 앞에서 설명한 이유 때문에 여전히 await! 에 찬성합니다. 그것은 Rust-y하고 말도 안되는 느낌입니다.

특히 긴 표현식이나 연결된 표현식의 경우 전반적인 가독성이 떨어집니다.

Rustfmt 표준에서 예제는 다음과 같이 작성되어야 합니다.

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

이것이 가독성에 어떤 영향을 미치는지 거의 알 수 없습니다.

나는 postfix await도 좋아합니다. 나는 공간을 사용하는 것이 이례적이고 정신적 그룹을 깨뜨리는 경향이 있다고 생각합니다. 그러나, 나는 생각합니까 .await!() 함께 잘 쌍 것 ? 이전 또는 이후 중 하나를 피팅하고, ! 제어 흐름의 상호 작용을 허용한다.

(완전히 일반적인 접미사 매크로 메커니즘이 필요하지 않습니다. 컴파일러는 특별한 경우 .await!() 있습니다.)

저는 await 접미사를 매우 싫어하기 시작했습니다( . 또는 () ). 확실히 비용. 그것은 우리가 진지하게 받아들여야 할 비용입니다. 그러나 x await 는 분명히 함수 호출이나 필드 액세스가 아니며( x.await / x.await() / await(x) 모두 이 문제가 있음) 펑키가 더 적습니다. 우선순위 문제. 이 구문은 ? 및 메서드 액세스 우선 순위를 명확하게 해결합니다(예: foo await? 및 foo? await foo await?.x 및 foo await?.y foo await?.x 및 foo await?.y 과 마찬가지로 둘 다 나에게 명확한 우선 순위 순서 지정).

나도 그렇게 생각한다

stream.for_each(async |item| {
    ...
}) await;

보다 잘 읽힌다

await!(stream.for_each(async |item| {
    ...
});

대체로 나는 이것을 지지할 것입니다.

@joshtriplett RE .await!() 우리는 별도로 이야기해야 합니다-- 나도 처음에는 이것에 찬성했지만 일반적으로 접미사 매크로도 얻을 수 없다면 이것을 착륙시켜야 한다고 생각하지 않습니다. 그들에 대한 상당한 반대파가 있고(불행한 이유이기는 하지만 꽤 좋은 일이지만) await 안정화를 방해하지 않았으면 합니다.

왜 모두?

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

나는 이제 postfix의 매력을 더 많이 보았고 일부 시나리오에서는 더 좋아하게 되었습니다. 특히 위의 치트는 너무 간단해서 Rust 자체에서 제공할 필요조차 없습니다.

따라서 접미사에 대해 +1입니다.

나는 우리가 접미사 버전 외에 접두사 기능 도 가져야 한다고 생각합니다.

접미사 구문의 세부 사항에 관해서는 .await!() 가 유일하게 실행 가능한 접미사 구문이라고 말하려는 것이 아닙니다. 나는 선행 공백이 있는 접미사 await 의 팬이 아닙니다.

한 줄에 하나의 명령문을 사용하여 형식을 지정하면 통과할 수 있는 것처럼 보이지만(여전히 이례적이지만) 간단한 명령문을 한 줄에 형식화하면 훨씬 덜 합리적입니다.

후위 키워드 연산자를 좋아하지 않는 사람들을 위해 await 적절한 기호 연산자를 정의할 수 있습니다.

바로 지금, 우리는 후위 연산자를 위한 간단한 ASCII 문자로 된 연산자가 부족했습니다. 그러나 어떻습니까

let x = do_something()⌛.do_somthing_else()⌛;

평범한 ASCII가 정말로 필요하다면 나는 (위의 모양에서 영감을 얻어) 생각해 냈습니다.

let x = do_something()><.do_somthing_else()><;

또는 (수평 위치의 시뮬레이트)

let x = do_something()>=<.do_somthing_else()>=<;

또 다른 아이디어는 await 구조체를 대괄호로 만드는 것입니다.

let x = >do_something()<.>do_something_else()<;

이러한 모든 ASCII 솔루션은 <..> 가 이미 과도하게 사용되고 있고 < 및 > 구문 분석 문제가 있다는 동일한 전달 문제를 공유합니다. 그러나 >< 또는 >=< 는 연산자 내부에 공간이 필요하지 않고 현재 위치에 열려 있는 < 가 없기 때문에 더 좋을 수 있습니다.

사이의 공백이 마음에 들지 않는 경우 접미사 키워드 연산자는 괜찮습니다. 하이픈을 사용하는 방법은 다음과 같습니다.

let x = do_something()-await.do_something_else()-await;

동일한 코드를 작성하는 다양한 방법이 있다는 점에 대해서는 개인적으로 좋아하지 않습니다. 새로운 사람들이 그것을 갖는 것이 올바른 방법이나 요점을 적절하게 이해하는 것이 훨씬 더 어려운 주된 이유입니다. 두 번째 이유는 우리가 다른 구문을 사용하는 많은 다른 프로젝트를 갖게 될 것이고 그것을 건너뛰고 읽는 것이 더 어려울 것이기 때문입니다(특히 녹슬기 시작한 신규 사용자의 경우). 실제로 차이가 있고 몇 가지 이점이 있는 경우에만 다른 구문을 구현해야 한다고 생각합니다. 많은 코드 설탕은 언어를 배우고 작업하는 것을 훨씬 더 어렵게 만듭니다.

@goffrie 예, 동일한 작업을 수행하는 데 여러 가지 다른 방법이 있어서는 안 된다는 데 동의합니다. 그러나 나는 단지 다른 대안을 제안했을 뿐입니다. 커뮤니티는 하나만 선택하면 됩니다. 따라서 이것은 실제로 문제가 되지 않습니다.

게다가, await! 매크로의 관점에서, 사용자가 그것을 다르게 하기 위해 그들 자신의 매크로를 발명하는 것을 막을 방법은 없으며, Rust는 이것을 가능하게 하기 위한 것입니다. 따라서 "같은 일을 하는 데 여러 가지 다른 방법이 있는 것"은 불가피합니다.

제가 보여드린 단순한 멍청한 매크로는 우리가 무엇을 하든 사용자가 원하는 것은 무엇이든 할 것이라는 것을 보여줍니다. 접두어든 접미사든 키워드는 함수와 같은 접두사 매크로로 만들거나, 존재할 때마다 아마도 접미사 메서드와 같은 매크로로 만들 수 있습니다. await 대해 함수 또는 메서드와 같은 매크로를 선택하더라도 다른 매크로로 반전될 수 있습니다. 그것은 정말 중요하지 않습니다.

따라서 유연성과 형식에 중점을 두어야 합니다. 이러한 모든 가능성을 가장 쉽게 채울 수 있는 솔루션을 제공하십시오.

게다가, 비록 이 짧은 시간에 내가 postfix 키워드 구문에 집착하게 되었지만, await 는 아마도 접두어 키워드일 가능성이 있는 제너레이터를 사용하여 yield 대해 결정된 모든 것을 미러링해야 합니다. 후위 솔루션을 원하는 사용자의 경우 메서드와 같은 매크로가 결국에는 존재할 것입니다.

내 결론은 접두어 키워드 await 가 현재로서는 가장 좋은 기본 구문이며 아마도 일반 상자에서 사용자에게 await! 매크로와 같은 기능을 제공하고 미래에는 접미사 메서드와 같은 .await!() 매크로.

@novacrazy

게다가, 비록 이 짧은 시간에 내가 postfix 키워드 구문에 집착하게 되었지만, await 는 아마도 접두어 키워드일 가능성이 있는 제너레이터를 사용하여 yield 대해 결정된 모든 것을 미러링해야 합니다.

yield 42 표현식은 ! 유형인 반면 foo.await 유형은 T foo: impl Future<Output = T> 입니다. @stjepang 은 여기에서 ? 및 return 올바르게 유추합니다. await 는 yield .

왜 모두?

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

await 는 true 키워드로 남아 있어야 하므로 매크로 이름을 다른 이름으로 지정해야 합니다.

다양한 이유로 저는 await 접두사를 반대하고 블록 형식 await { ... } 반대합니다.

먼저 일관된 우선 순위가 await (expr?) 이지만 (await expr)? 원하는 await expr? 의 우선 순위 문제가 있습니다. 우선 순위 문제에 대한 해결책으로 일부에서는 await expr 외에 await? expr 를 제안했습니다. 여기에는 await? 단위와 특수 케이스가 필요합니다. 이는 정당하지 않은 것으로 보이며 복잡성 예산의 낭비이며 await expr 에 심각한 문제가 있음을 나타냅니다.

더 중요한 것은, Rust 코드와 특히 표준 라이브러리는 점과 메서드 호출 구문의 힘에 집중되어 있다는 것입니다. await 가 접두어일 때 사용자가 단순히 메서드를 연결하는 대신 임시 let 바인딩을 만들도록 권장합니다. 이것이 ? 가 후위인 이유이고, 같은 이유로 await 도 후위여야 합니다.

더 나쁜 것은 await { ... } 입니다. 이 구문은 rustfmt 에 따라 일관되게 형식이 지정되면 다음과 같이 바뀝니다.

    let x = await { // by analogy with `loop`
        foo.bar.baz.other_thing()
    };

이것은 인체공학적이지 않고 기능의 수직 길이를 크게 부풀리게 합니다.

대신 ? 와 같이 awaiting 은 메서드 연결을 중심으로 하는 Rust 생태계에 적합하기 때문에 접미사여야 한다고 생각합니다. 많은 접미사 구문이 언급되었습니다. 그 중 일부를 살펴보겠습니다.

1. foo.await!() -- 이것은 접미사 매크로 솔루션입니다. 나는 후위 매크로에 찬성 강하게 해요 동안, 나는가 동의와 @cramertj에 https://github.com/rust-lang/rust/issues/50547#issuecomment -454225040 우리는 또한 후위에 투입하지 않는 한 우리는이 작업을 수행해서는 안 일반적으로 매크로. 나는 또한 이런 식으로 접미사 매크로를 사용하는 것이 다소 비일류적인 느낌을 준다고 생각합니다. 우리는 매크로 구문을 사용하는 언어 구성을 피해야 합니다.

2. foo await -- 이것은 그리 나쁘지 않습니다. 이것은 실제로 후위 연산자( expr op )처럼 작동하지만 이 형식에 뭔가 빠진 것이 있는 것 같습니다(즉, "빈" 느낌). 대조적으로 expr? ? 를 expr 직접 첨부합니다. 여기에 공간이 없습니다. 이것은 ? 를 시각적으로 매력적으로 보이게 합니다.

3. foo.await -- 이것은 필드 액세스처럼 보인다는 비판을 받았습니다. 그리고 그것은 사실입니다. 그러나 await 는 키워드이므로 구문이 강조 표시된다는 점을 기억해야 합니다. IDE에서 또는 이에 상응하는 GitHub에서 Rust 코드를 읽는 경우 await 는 foo 와 다른 색상이나 굵게 표시됩니다. 다른 키워드를 사용하여 다음을 시연할 수 있습니다.

   let x = foo.match?;
   

   관례적으로 필드는 명사인 반면 await 는 동사입니다.

   foo.await 에 대한 초기 조롱 요소가 있지만 시각적으로 매력적이면서 읽을 수 있는 구문으로 진지하게 고려해야 한다고 생각합니다.

   보너스로 .await 사용하면 IDE에서 일반적으로 사용 하는 점 과 자동 완성 기능을 사용할 수 있습니다 (56페이지 참조). 예를 들어 foo. 쓸 수 있으며 foo 가 미래일 경우 await 가 첫 번째 선택으로 표시됩니다. 점에 도달하는 것은 많은 개발자가 근육 기억에 대해 훈련한 것이기 때문에 이는 인체 공학 및 개발자 생산성을 모두 촉진합니다.

   가능한 모든 접미사 구문에서 필드 액세스처럼 보인다는 비판에도 불구하고 이것이 내가 가장 좋아하는 구문으로 남아 있습니다.

4. foo# -- # 를 기다리기 위해 foo 합니다. ? 도 인장이고 awaiting 경량이기 때문에 인장을 고려하는 것은 좋은 생각이라고 생각합니다. ? 와 결합하면 foo#? 처럼 보입니다. 괜찮아 보입니다. 그러나 # 에는 특별한 근거가 없습니다. 오히려 아직 사용 가능한 인장일 뿐입니다.

5. foo@ -- 또 다른 인장은 @ 입니다. ? 와 결합하면 foo@? 됩니다. 이 특정 인장에 대한 한 가지 정당성은 a -ish ( @wait )로 보인다는 것입니다.

6. foo! -- 마지막으로 ! 있습니다. ? 와 결합하면 foo!? 됩니다. 불행히도 이것은 WTF 느낌이 있습니다. 그러나 ! 는 "await"에 맞는 값을 강제 실행하는 것처럼 보입니다. foo!() 이미 합법적인 매크로 호출이므로 함수를 기다리고 호출하는 것은 (foo)!() 로 작성해야 한다는 단점이 있습니다. foo! 를 구문으로 사용하면 키워드 매크로(예: foo! expr )를 가질 기회도 박탈됩니다.

또 다른 단일 인장은 foo~ 입니다. 파도는 "에코" 또는 "시간이 걸린다"로 이해될 수 있습니다. 그러나 이것은 Rust 언어의 어느 곳에서도 사용되지 않습니다.

물결표 ~ 는 옛날에 힙 할당 유형에 사용되었습니다. https://github.com/rust-lang/rfcs/blob/master/text/0059-remove-tilde.md

? 을 재사용할 수 있습니까? 아니면 너무 많은 마법입니까? impl Try for T: Future 은(는) 어떻게 생겼나요?

@parasyte 네 기억합니다. 그러나 그것은 여전히 ​​오래되었습니다.

@jethrogb impl Try 직접 작동하는 것을 볼 수 있는 방법은 없습니다. ? 명시적으로 return s 현재 함수에서 Try 의 결과인 동안 await 는 yield await 이어야 합니다.

아마도 ? 는 적용되는 표현식의 유형에 따라 yield 또는 return yield 수 있도록 생성기의 컨텍스트에서 다른 작업을 수행하기 위해 특수한 경우일 수 있습니다. , 하지만 그것이 얼마나 이해할 수 있을지 모르겠습니다. 또한 방법과 상호 작용하는 것 Future<Output=Result<...>> , 당신이해야합니다 let foo = bar()??; 모두 않는다 "AWAIT"다음 얻을 Ok 의 변형을 Result ( 아니면 yield , return 또는 단일 응용 프로그램으로 값을 확인할 수 있는 yield 특성을 기반으로 하는 생성기의 ? 입니까?

enum GenOp<T, U, E> { Break(T), Yield(U), Error(E) }

trait TryGen {
    type Ok;
    type Yield;
    type Error;

    fn into_result(self) -> GenOp<Self::Ok, Self::Yield, Self::Error>;
}

loop {
    match TryGen::into_result(foo) {
        GenOp::Break(val) => break val,
        GenOp::Yield(val) => yield val,
        GenOp::Return(val) => return Try::from_error(val.into()),
    }
}

불행히도 나는 이와 같은 체계에서 깨우기 컨텍스트 변수를 처리하는 방법을 알지 못합니다. 아마도 ? 가 생성기 대신 async 에 대해 특수한 경우일 수 있지만 특별할 경우 -여기서 다른 생성기 사용 사례에 사용할 수 있다면 좋을 것입니다.

? 재사용에 대해 @jethrogb와 같은 생각을 했습니다.

@Nemo157

내가 볼 수있는 방법은 없습니다 impl Try 직접 작업, ? 명시 적으로 return 의 결과에요 Try 현재 함수에서이 잠시 기다리고 있습니다 요구 yield .

아마도 ? 및 Try 특성에 대한 세부 정보가 누락되었을 수 있지만 명시적 위치/이유는 무엇입니까? 그리고 비동기 클로저의 return 는 기본적으로 yield 와 기본적으로 동일하지 않고 단지 다른 상태 전환일 뿐입니다.

아마도 ? 는 적용되는 표현식의 유형에 따라 yield 또는 return yield 수 있도록 생성기의 컨텍스트에서 다른 작업을 수행하기 위해 특수한 경우일 수 있습니다. , 하지만 그것이 얼마나 이해할 수 있을지 모르겠습니다.

왜 그것이 혼란스러워야 하는지 모르겠습니다. ? 를 "계속 또는 발산"이라고 생각하면 자연스럽게 보입니다. IMHO. 물론 Try 특성을 관련 반환 유형에 대해 다른 이름을 사용하도록 변경하면 도움이 됩니다.

또한 그것이 Future<Output=Result<...>> 와 어떻게 상호 작용할까요? let foo = bar()?? 합니까?

결과를 기다리고 오류 결과에서 일찍 종료하려는 경우 논리 표현식이 됩니다. 예. 나는 특별한 tri-state TryGen 가 전혀 필요하지 않을 것이라고 생각합니다.

불행히도 나는 이와 같은 체계에서 깨우기 컨텍스트 변수를 처리하는 방법을 알지 못합니다. 아마도 if ? 제너레이터 대신 비동기에 대해 특수 케이스가 있었지만 여기에서 특수 케이스가 된다면 다른 제너레이터 유스 케이스에 사용할 수 있다면 좋을 것입니다.

이 부분이 이해가 되지 않습니다. 자세히 설명해 주시겠습니까?

@jethrogb @rolandsteiner 구조체는 Try 및 Future 모두를 구현할 수 있습니다. 이 경우 어떤 것을 ? 풀어야 할까요?

@jethrogb @rolandsteiner 구조체는 Try와 Future를 모두 구현할 수 있습니다. 이 경우 어느 쪽을 선택해야 합니까? 풀다?

아니요. T: Future를 위한 포괄적인 암시 때문에 그럴 수 없었습니다.

명시적 구성과 암시적 대기 제안에 대해 아무도 이야기하지 않는 이유는 무엇입니까? 스레드 대신 작업을 차단한다는 점만 제외하면 sync io와 동일합니다. 스레드를 차단하는 것이 작업을 차단하는 것보다 더 침습적이라고 말할 수도 있습니다. 그렇다면 왜 thread-blocking-io에 대한 특별한 "await" 구문이 없을까요?

하지만 그것은 모두 자전거 셰이딩에 불과합니다. 제 생각에는 적어도 지금은 간단한 매크로 구문 await!(my_future) 정착해야 한다고 생각합니다.

하지만 그것은 모두 자전거 셰이딩에 불과합니다. 제 생각에는 적어도 지금은 간단한 매크로 구문 await!(my_future) 정착해야 한다고 생각합니다.

아니요, 마치 그것이 진부하고 중요하지 않은 것처럼 "그냥" 자전거를 타는 것이 아닙니다. await 가 접두사인지 접미사인지는 비동기 코드가 wrt로 작성되는 방식에 근본적으로 영향을 미칩니다. 메소드 체이닝과 그것이 얼마나 구성 가능한지. await!(future) 에 대한 안정화는 또한 await 를 키워드로 포기하여 향후 await 를 키워드로 사용할 수 없도록 합니다. "적어도 지금은"은 나중에 더 나은 구문을 찾을 수 있고 이에 수반되는 기술적 부채를 무시할 수 있음을 나타냅니다. 나는 나중에 교체될 구문에 대해 고의로 부채를 도입하는 것을 반대합니다.

await!(future)에서 안정화하는 것은 또한 await를 키워드로 포기하는 것을 수반하므로 향후 await를 키워드로 사용할 수 없습니다.

try 했던 것처럼 매크로에 대한 원시 ident 구문이 필요한 다음 시대에 키워드로 만들 수 있습니다.

@chpio await 는 이미 Rust 2018의 키워드입니다.

@rolandsteiner

그리고 비동기 클로저의 return 는 기본적으로 yield 와 기본적으로 동일하지 않고 단지 다른 상태 전환일 뿐입니다.

yield 는 비동기 클로저에 존재하지 않으며 async / await 구문에서 generators/ yield 낮추는 동안 도입된 작업입니다. 현재 생성기 구문에서 yield 는 return 와 상당히 다릅니다. ? 확장이 생성기 변환 전에 완료되면 삽입 시점을 어떻게 알 수 있을지 모르겠습니다. return 또는 yield .

결과를 기다리고 오류 결과에서 nalso가 일찍 종료되기를 원한다면 그것은 논리적 표현식이 될 것입니다. 예.

논리적일 수 있지만 비동기 함수를 작성하는 많은(대부분?) 경우가 IO 오류를 처리하기 위해 이중 ?? 로 채워진다는 것이 나에게는 단점으로 보입니다.

불행히도 깨우기 컨텍스트 변수를 처리하는 방법을 알지 못합니다 ...

이 부분이 이해가 되지 않습니다. 자세히 설명해 주시겠습니까?

비동기 변환은 생성된 Future::poll 함수에서 깨우기 변수를 사용하며, 이 변수를 변환된 대기 작업에 전달해야 합니다. 현재 이것은 std 제공하는 TLS 변수로 처리되며 두 변환 모두 참조합니다. ? 가 대신 _생성기 수준에서_ 재항복 지점으로 처리되면 비동기 변환이 손실됩니다. 이 변수 참조를 삽입합니다.

나는 두 달 전에 내 선호도를 설명하는 await 구문에 대한 블로그 게시물을 작성

• 내 일반적인 의견은 Rust가 이미 익숙하지 않은 예산을 실제로 늘렸다는 것입니다. 표면 수준 async/await 구문은 JavaScript, Python 또는 C#에서 오는 사람에게 가능한 한 친숙한 것이 이상적입니다. 이러한 관점에서 규범에서 약간만 벗어나는 것이 이상적일 것입니다. 접미사 구문은 분기의 정도에 따라 다릅니다(예: foo await 는 foo@ 와 같은 일부 기호보다 분기가 적음). 그러나 모두 접두어가 기다리는 것보다 더 다양합니다.
• 또한 ! 사용하지 않는 구문을 안정화하는 것을 선호합니다. async/await를 다루는 모든 사용자는 왜 await가 일반적인 제어 흐름 구조가 아닌 매크로인지 궁금해 할 것입니다. 저는 여기서 이야기가 본질적으로 "글쎄 우리는 좋은 구문을 알아낼 수 없어서 그냥 매크로처럼 보이게 합니다." 이것은 설득력 있는 대답이 아닙니다. 나는 사이의 연관 생각하지 않는다 ! 및 제어 흐름이 정말로 충분이 구문을 정당화하는 것입니다 : 내가 믿는 ! 이없는이 꽤 특히 평균 매크로 expension.
• 나는 일종의 접미사의 이익의 의심의이야 (전적으로 단지 종류의) 일반적으로 기다리고 있습니다. 나는 균형이 ? 와 약간 다르다고 생각합니다. 왜냐하면 awaiting은 더 비싼 작업이기 때문입니다(단지 분기하고 한 번 반환하는 것이 아니라 준비가 될 때까지 루프에서 양보합니다). 단일 표현식에서 두세 번 대기하는 코드가 의심스럽습니다. 이것들이 그들 자신의 let 바인딩으로 당겨져야 한다고 말하는 것이 나에게는 괜찮은 것 같습니다. 따라서 try! 대 ? 절충은 여기에서 나에게 강력하게 당기지 않습니다. 그러나 또한 사람들이 실제로 let으로 꺼내서는 안 되며 메서드 체인으로 더 명확하다고 생각하는 코드 샘플에 대해 열려 있습니다.

즉, foo await 는 지금까지 본 것 중 가장 실행 가능한 접미사 구문입니다.

• 접미사 구문에 비교적 익숙합니다. 당신이 배워야 할 것은 await가 매우 다른 구문이 아니라 Rust에서 표현식 뒤에 온다는 것입니다.
• 이 모든 것이 다루어진 우선 순위 문제를 명확하게 해결합니다.
• 메소드 체이닝과 잘 작동하지 않는다는 사실은 내가 이전에 언급한 이유로 단점이 아니라 거의 장점으로 보입니다. 우리가 방지 몇 가지 문법 규칙이 있다면 좀 더 강요 될 수 foo await.method() 정말 방법이되고있는 느낌을해서 (무의미)에 적용 await 하지 foo (반면 흥미롭게 foo await? 에서는 그렇게 느껴지지 않습니다.

나는 여전히 접두사 구문에 기대고 있지만 await 가 첫 번째 접미사 구문이라고 생각합니다.

참고: 우선 순위를 더 명확하게 하기 위해 항상 괄호를 사용할 수 있습니다.

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

꼭 이상적인 것은 아니지만 한 줄에 많은 것을 담으려는 것을 생각하면 합리적이라고 생각합니다.

그리고 앞서 언급한

let x = x.do_something() await
         .do_another_thing() await;

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

• 표면 수준 async/await 구문은 JavaScript, Python 또는 C#에서 오는 사람에게 가능한 한 친숙한 것이 이상적입니다.

try { .. } 경우 다른 언어에 대한 친숙도를 고려했습니다. 그러나 이것은 또한 Rust와 내부 일관성의 POV에서 올바른 디자인이었습니다. 따라서 이러한 다른 언어에 대한 모든 적절한 존중과 함께 Rust의 내부 일관성이 더 중요해 보이며 접두사 구문이 우선 순위 또는 API 구조 측면에서 Rust에 적합하지 않다고 생각합니다.

• 또한 ! 사용하지 않는 구문을 안정화하는 것을 선호합니다. async/await를 다루는 모든 사용자는 왜 await가 일반적인 제어 흐름 구조가 아닌 매크로인지 궁금해 할 것입니다. 저는 여기서 이야기가 본질적으로 "글쎄 우리는 좋은 구문을 알아낼 수 없어서 그냥 매크로처럼 보이게 합니다." 이것은 설득력 있는 대답이 아닙니다.

나는 이 감정에 동의합니다. .await!() 는 일류처럼 보이지 않을 것입니다.

• 나는 일반적으로 postfix await의 이점에 대해 회의적입니다. 나는 균형이 ? 와 약간 다르다고 생각합니다. awaiting은 더 비용이 많이 드는 작업이기 때문입니다.

let 바인딩으로 물건을 추출하는 것과 비용이 어떤 관련이 있는지 모르겠습니다. 메소드 체인은 비용이 많이 들 수 있으며 때로는 비용이 많이 듭니다. let 바인딩의 이점은 a) 가독성을 높이는 데 의미가 있는 충분히 큰 조각에 이름을 부여하고, b) 동일한 계산 값을 두 번 이상 참조할 수 있다는 것입니다(예: &x 또는 유형이 복사 가능한 경우).

단일 표현식에서 두세 번 대기하는 코드가 의심스럽습니다. 이것들이 그들 자신의 let 바인딩으로 당겨져야 한다고 말하는 것이 나에게는 괜찮은 것 같습니다.

자신의 let 바인딩으로 가져와야 한다고 생각되면 await 접미사로 여전히 선택할 수 있습니다.

let temporary = some_computation() await?;

동의하지 않고 메서드 연결을 선호하는 사람들을 위해 접미사 await 사용하면 선택할 수 있습니다. 나는 또한 postfix가 여기에서 왼쪽에서 오른쪽 읽기 및 데이터 흐름 순서를 더 잘 따른다고 생각하므로 let 바인딩으로 추출하더라도 여전히 postfix를 선호합니다.

또한 await 접미사가 유용하기 위해 두세 번 기다릴 필요가 없다고 생각합니다. 예를 들어( rustfmt 의 결과임):

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

그러나 또한 사람들이 실제로 let으로 꺼내서는 안 되며 메서드 체인으로 더 명확하다고 생각하는 코드 샘플에 대해 열려 있습니다.

내가 읽은 자홍색 코드의 대부분은 let 바인딩과 let binding = await!(...)?; 로 추출할 때 부자연스럽게 느껴졌습니다.

• 접미사 구문에 비교적 익숙합니다. 당신이 배워야 할 것은 await가 매우 다른 구문이 아니라 Rust에서 표현식 뒤에 온다는 것입니다.

여기서 foo.await 대한 선호도는 주로 멋진 자동 완성과 점의 힘을 얻을 수 있기 때문입니다. 크게 달라진 느낌도 없습니다. foo.await.method() 를 쓰면 .method() 가 foo.await 적용된다는 것도 더 명확해집니다. 그래서 그 고민을 해결합니다.

• 이 모든 것이 다루어진 우선 순위 문제를 명확하게 해결합니다.

아니요, 우선 순위에 관한 것이 아닙니다. 메소드 체인도 똑같이 중요합니다.

• 메소드 체이닝과 잘 작동하지 않는다는 사실은 내가 이전에 언급한 이유로 단점이 아니라 거의 장점으로 보입니다.

메서드 체이닝에서 잘 작동하지 않는 이유를 잘 모르겠습니다.

우리가 방지 몇 가지 문법 규칙이 있다면 좀 더 강요 될 수 foo await.method() 정말 방법이되고있는 느낌을해서 (무의미)에 적용 await 하지 foo (반면 흥미롭게 foo await? 에서는 그렇게 느껴지지 않습니다.

반면에 의도적인 디자인 페이퍼컷을 도입하고 접미사 await 구문으로 메서드 연결을 방지했다면 foo await 하지 않을 것입니다.

모든 옵션에는 단점이 있고 그 중 하나가 선택되어야 한다는 사실을 인정하면... foo.await 에 대해 나를 괴롭히는 한 가지는 그것이 문자 그대로 오해 되지 않을 것이라고 가정하더라도 구조체 필드, 여전히 구조체 필드에 액세스하는 것처럼 보입니다 . 필드 액세스의 의미는 특별히 영향력 있는 일은 일어나지 않는다는 것입니다. 이것은 Rust에서 가장 효과가 적은 작업 중 하나입니다. 한편, 대기는 가장 사이드 행하는 연산 한 매우 효과적인 것이다 (이를 I / O 동작이 미래에 구축 및 제어 흐름 효과가 모두 수행한다). 그래서 내가 foo.await.method() 읽을 때 내 두뇌는 상대적으로 흥미롭지 않기 때문에 .await 를 건너뛰라고 말하고 있으며 그 본능을 수동으로 무시하려면 주의와 노력을 기울여야 합니다.

여전히 구조체 필드에 액세스하는 _모양_입니다.

@glaebhoerl 좋은 지적을 .await 를 건너뛰지 않을 것입니다.

필드 액세스의 의미는 특별히 영향력 있는 일은 일어나지 않는다는 것입니다. 이것은 Rust에서 가장 효과가 적은 작업 중 하나입니다. 한편 기다림은 가장 부작용이 많은 작업 중 하나인 매우 영향력이 있습니다(미래에 구축된 I/O 작업을 수행하고 흐름 제어 효과가 있음).

나는 이것에 강력히 동의합니다. await 는 break 또는 return 와 같은 제어 흐름 작업이며 명시적이어야 합니다. 제안된 후위 표기법은 Python의 if 처럼 부자연스럽게 느껴집니다. compare if c { e1 } else { e2 } to e1 if c else e2 . 마지막에 연산자를 보면 구문 강조 표시에 관계없이 이중 작업을 수행하게 됩니다.

또한 e.await 가 await!(e) 또는 await e 보다 Rust 구문과 더 일관성이 있다는 것도 알 수 없습니다. 다른 접미사 키워드는 없으며, 아이디어 중 하나는 구문 분석기에서 특수 케이스를 지정하는 것이었기 때문에 이것이 일관성의 증거가 아니라고 생각합니다.

언급된 @withoutboats 친숙성 문제도 있습니다. 몇 가지 놀라운 이점이 있다면 이상하고 멋진 구문을 선택할 수 있습니다. 그러나 접미사 await 에 그것들이 있습니까?

구문 강조 표시는 모양과 뇌가 사물을 처리하는 방식에 영향을 미치지 않거나 충분하지 않습니까?

(좋은 질문은, 나는 그것이 어떤 영향을 미칠 것이라고 확신하지만 우리가 주제에있는 동안 얼마나 실제로 그것을 시도 (과) 만 가져 지금까지 다른 키워드를 대체하지 않고. 추측 ... 오랜 시간이 어렵다 제가 말씀 드린 전, 구문 강조는 제어 흐름 효과를 모든 사업자 (강조해야한다고 생각한다는 return , break , continue , ? ... 지금과 await ) 특별한 색으로 표시되지만 저는 구문 강조 표시를 담당하지 않으며 실제로 이 작업을 수행하는 사람이 있는지 모르겠습니다.)

나는 이것에 강력히 동의합니다. await 는 break 또는 return 와 같은 제어 흐름 작업이며 명시적이어야 합니다.

우리는 동의한다. foo.await , foo await , foo# , ... 표기법 은 명시적 입니다. 암묵적인 대기가 완료되지 않습니다.

또한 e.await 가 await!(e) 또는 await e 보다 Rust 구문과 더 일관성이 있다는 것도 알 수 없습니다.

e.await 자체 구문은 Rust 구문과 일치하지 않지만 일반적으로 접미사는 ? 및 Rust API가 구조화되는 방식에 더 적합합니다(방법이 자유 함수보다 선호됨).

await e? 구문으로 연결된 경우 (await e)? 방법과 완전히 일치하지 break 및 return 연관. await!(e) 역시 제어 흐름을 위한 매크로가 없기 때문에 일관성이 없고 다른 접두사 메서드와 동일한 문제가 있습니다.

다른 접미사 키워드는 없으며, 아이디어 중 하나는 구문 분석기에서 특수 케이스를 지정하는 것이었기 때문에 이것이 일관성의 증거가 아니라고 생각합니다.

.await 대해 libsyntax를 실제로 변경할 필요가 없다고 생각합니다. 이미 필드 작업으로 처리되어야 하기 때문입니다. 논리는 특수 구조로 변환하는 resolve 또는 HIR에서 처리하는 것이 좋습니다.

몇 가지 놀라운 이점이 있다면 이상하고 멋진 구문을 선택할 수 있습니다. 그러나 접미사 await 에 그것들이 있습니까?

앞서 언급한 바와 같이, 나는 이것이 메소드 체인과 Rust의 메소드 호출 선호도 때문이라고 주장합니다.

이미 필드 작업으로 처리되어야 하기 때문에 .await에 대해 libsyntax를 실제로 변경할 필요가 없다고 생각합니다.

이 재미.
따라서 아이디어는 self / super ...의 접근 방식을 재사용하지만 경로 세그먼트가 아닌 필드에 사용하는 것입니다.

이렇게 하면 await 경로 세그먼트 키워드가 효과적으로 만들어지므로(분석을 거치기 때문에) 이에 대한 원시 식별자 를

#[derive(Default)]
struct S {
    r#await: u8
}

fn main() {
    let s = ;
    let z = S::default().await; //  Hmmm...
}

암묵적인 대기가 완료되지 않습니다.

아이디어는 이 스레드("암시적 대기" 제안)에서 두 번 나왔습니다.

제어 흐름을 위한 매크로가 없습니다.

try! (이는 목적을 잘 수행함) 가 있으며 틀림없이 사용되지 않는 select! 입니다. await 는 return 보다 "더 강력"하므로 ? 의 return 보다 코드에서 더 잘 보일 것으로 기대하는 것이 무리가 아닙니다.

나는 그것이 메소드 체인과 메소드 호출에 대한 Rust의 선호도 때문이라고 주장합니다.

또한 접두사 제어 흐름 연산자에 대한 (더 눈에 띄는) 기본 설정이 있습니다.

기다려 전자? (await e)로 연결된 경우 구문? break 및 return 연관 방법과 완전히 일치하지 않습니다.

나는 await!(e)? , await { e }? 또는 심지어 { await e }? 선호합니다 -- 저는 후자가 논의되는 것을 본 적이 없다고 생각합니다. 그리고 그것이 작동하는지 확신할 수 없습니다.

좌우 편향이 있을 수 있음을 인정합니다. _메모_

이에 대한 내 생각은 문제를 볼 때마다 마치 악마의 옹호자 역할을 하는 것처럼 바뀌는 것 같습니다. 그 중 일부는 내가 내 미래와 상태 머신을 작성하는 데 너무 익숙하기 때문입니다. poll 의 맞춤형 미래는 완전히 정상입니다.

아마도 이것은 다른 방식으로 생각해야 합니다.

나에게 Rust의 제로 비용 추상화는 런타임에 제로 비용과 더 중요하게는 정신적으로 제로 비용이라는 두 가지를 나타냅니다.

나는 미래를 포함하여 Rust의 대부분의 추상화에 대해 매우 쉽게 추론할 수 있습니다. 왜냐하면 그것들은 단지 상태 기계이기 때문입니다.

이를 위해서는 사용자에게 최소한의 마법을 도입하는 간단한 솔루션이 존재해야 합니다. 특히 인장은 불필요하게 마법 같은 느낌을 주기 때문에 좋지 않습니다. 여기에는 .await 매직 필드가 포함됩니다.

아마도 가장 좋은 솔루션은 가장 쉬운 솔루션인 원래 await! 매크로일 것입니다.

따라서 이러한 다른 언어에 대한 모든 적절한 존중과 함께 Rust의 내부 일관성이 더 중요해 보이며 접두사 구문이 우선 순위 또는 API 구조 측면에서 Rust에 적합하지 않다고 생각합니다.

잘 모르겠어...? await(foo)? / await { foo }? 는 연산자 우선 순위와 API가 Rust에서 어떻게 구조화되어 있는지 면에서 완전히 괜찮아 보입니다. 단점은 괄호와 (당신의 관점에 따라) 연결의 장황함입니다. 혼란스러운.

try! (이는 목적을 잘 수행함) 가 있으며 틀림없이 사용되지 않는 select! 입니다.

나는 여기에서 작동하는 단어가 더 이상 사용되지 않는다고 생각합니다. try!(...) 를 사용하는 것은 Rust 2018에서 하드 오류입니다. 더 나은 일급 및 접미사 구문을 도입했기 때문에 이제는 어려운 오류입니다.

await 는 return 보다 "더 강력"하므로 ? 의 return 보다 코드에서 더 잘 보일 것으로 기대하는 것이 무리가 아닙니다.

? 연산자는 마찬가지로 부작용이 있을 수 있으며( Result 이외의 다른 구현을 통해) 제어 흐름을 수행하므로 매우 "강력합니다". 논의 당시 ? 는 '반품을 숨기고 간과하기 쉽다 await 저와 상당히 비슷해 보입니다.

또한 접두사 제어 흐름 연산자에 대한 (더 눈에 띄는) 기본 설정이 있습니다.

이러한 접두사 제어 흐름 연산자는 ! 유형으로 입력됩니다. 한편 impl Try<Ok = T, ...> 컨텍스트를 사용하여 T 제공하는 다른 제어 흐름 연산자 ? T 는 접미사입니다.

잘 모르겠어...? await(foo)? / await { foo }? 는 연산자 우선 순위와 API가 Rust-

await(foo) 구문은 괄호가 전자에 필요하고 후자가 아닌 경우 await foo 와 동일하지 않습니다. 전자는 전례가 없고 후자는 우선순위 문제가 있습니다. ? 여기, 보트 블로그 게시물 및 Discord에서 논의했습니다. await { foo } 구문은 다른 이유로 문제가 됩니다(https://github.com/rust-lang/rust/issues/50547#issuecomment-454313611 참조).

그것의 단점은 괄호와 (관점에 따라) 연결의 장황함이며, 선례를 어기거나 혼란스럽지 않습니다.

이것이 내가 "API가 구조화되어 있다"는 의미입니다. 저는 메소드와 메소드 체인이 Rust에서 일반적이고 관용적이라고 생각합니다. 접두어 및 블록 구문은 해당 구문과 ? 구성되지 않습니다.

나는 이 의견이 소수일 수 있습니다. 그렇다면 저를 무시하십시오.

접두사 대 접미사 토론을 내부 스레드로 옮기고 결과를 가지고 여기로 돌아오는 것이 공정할까요? 그렇게 하면 기능 의 상태 를

@seanmonstar 예, 추적 문제에 대한 논의를 제한하고 실제로 상태 업데이트에 불과한 문제를 갖고자 하는 바람에 강력하게 동감합니다. 이것은 RFC 프로세스 및 일반적인 문제를 관리하는 방법에 대한 약간의 수정으로 해결할 수 있기를 바라는 문제 중 하나입니다. 지금은 토론에 사용할 새 문제를 여기 에서 열었습니다.

모두에게 중요: 추가 await 구문 논의는 여기에 있어야

await 구문에 대한 향후 논의가 해당 문제에 대해 논의될 수 있도록 하루 동안 일시적으로 잠급니다.

2019년 1월 15일 화요일 07:10:32AM -0800에서 Pauan은 다음과 같이 썼습니다.

참고: 우선 순위를 더 명확하게 하기 위해 항상 괄호를 사용할 수 있습니다.

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

그것은 postfix await의 주요 이점을 무효화합니다: "그냥 유지하십시오.
쓰기/읽기". 접미사는 ? 접미사처럼 제어 흐름을 허용합니다.
왼쪽에서 오른쪽으로 계속 이동하려면:

foo().await!()?.bar().await!()

await! 가 접두어인 경우 또는 try! 가 접두어일 때 뒤로 또는 다음이 있는 경우
괄호로 묶으려면 왼쪽으로 돌아가야 합니다.
쓰거나 읽을 때의 표현.

편집: 나는 이메일을 통해 처음부터 끝까지 댓글을 읽고 있었고 이 메일을 보내기 전까지 "대화를 다른 문제로 이동" 댓글을 보지 못했습니다.

링크 업데이트: https://github.com/rust-lang/rust/issues/53259 및 https://github.com/rust-lang/rust/issues/53447 이 폐쇄된 것 같습니다. https://github.com/rust-lang-nursery/futures-rs/issues/1199 가 .

비동기 대기 상태 보고서:

http://smallcultfollowing.com/babysteps/blog/2019/03/01/async-await-status-report/

async-await 상태에 대한 빠른 업데이트를 게시하고 싶었습니다.
노력. 짧은 버전은 우리가 홈 스트레치 에 있다는 것입니다.
어떤 종류의 안정화, 그러나 몇 가지 중요한
극복해야 할 질문.

구현 작업 그룹 발표

이러한 노력의 일환으로
async-await 구현 작업 그룹 . 이 작업 그룹
전체 async-wait 노력의 일부이지만
구현이며 컴파일러 팀의 일부입니다. 원하는 경우
결승선에 대한 비동기 대기를 도와주세요. 문제 목록이 있습니다.
우리가 확실히 도움이 필요한 곳(계속 읽어보기).

참여에 관심이 있으시면 "사무실 시간"이 있습니다.화요일로 예정되어 있습니다([컴파일러 팀 캘린더] 참조) -- 만약 당신이
그러면 [Zulip]에 표시될 수 있다면 이상적일 것입니다! (그렇지 않다면 아무거나 팝니다.
시각.)

...

https://github.com/rust-lang/rust/issues/59001

std::future::Future 언제 안정화되나요? 비동기 대기를 기다려야 합니까? 나는 그것이 아주 멋진 디자인이라고 생각하고 그것에 코드 포팅을 시작하고 싶습니다. (스테이블에서 사용하는 심이 있나요?)

@ry 새로운 추적 문제를 참조하십시오: https://github.com/rust-lang/rust/issues/59113

async/await에 대한 또 다른 컴파일러 문제: https://github.com/rust-lang/rust/issues/59245

또한 상단 게시물의 https://github.com/rust-lang-nursery/futures-rs/issues/1199 는 이제 수정되었으므로 체크 해제할 수 있습니다.

HRLB 및 비동기 폐쇄에 문제가 있는 것 같습니다: https://github.com/rust-lang/rust/issues/59337. (그러나 RFC를 다시 훑어보면 실제로 비동기 클로저가 비동기 함수와 동일한 인수 수명 캡처 대상임을 지정하지 않습니다.)

네, 비동기 클로저에는 많은 문제가 있으며 초기 안정화 단계에 포함되어서는 안 됩니다. 현재 동작은 클로저 + 비동기 블록으로 에뮬레이트될 수 있으며 미래에는 반환된 미래에서 클로저의 upvar를 참조할 수 있는 버전을 보고 싶습니다.

나는 현재 await!(fut) 가 fut 가 Unpin 되어야 한다는 것을 알았습니다. https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist= 9c189fae3cfeecbb041f68f02f31893d

예상인가요? RFC에 없는 것 같습니다.

@Ekleog 는 await! 오류를 제공하지 않으며 await! 는 전달된 미래를 개념적으로 스택 고정하여 !Unpin 선물을 사용할 수 있도록 합니다( 빠른 플레이그라운드 예 ). 오류는 impl Future for Box<impl Future + Unpin> 에 대한 제약 조건에서 발생합니다. 이 제약 조건에서는 다음과 같은 작업을 중지하기 위해 future가 Unpin 여야 합니다.

// where Foo: Future + !Unpin
let mut foo: Box<Foo> = ...;
Pin::new(&mut foo).poll(cx);
let mut foo = Box::new(*foo);
Pin::new(&mut foo).poll(cx);

Box 는 Unpin 이고 여기에서 값을 이동할 수 있기 때문에 하나의 힙 위치에서 미래를 한 번 폴링한 다음, 미래를 상자에서 꺼내 새 힙 위치에 넣고 폴링할 수 있습니다. 다시.

await는 미래를 소비하기 때문에 Box<dyn Future> 를 허용하는 특수 케이스여야 합니다.

IntoFuture 특성이 await! 대해 부활해야 할까요? Box<dyn Future> 는 Pin<Box<dyn Future>> 로 변환하여 구현할 수 있습니다.

async/await에 대한 다음 버그는 다음과 같습니다. async fn 의 반환 유형에서 유형 매개변수에 연결된 유형을 사용하면 추론이 중단됩니다. https://github.com/rust-lang/rust/ 문제/60414

잠재적으로 #60414를 top-post의 목록에 추가하는 것 외에도(아직 사용 중인지 모르겠지만 github 레이블을 가리키는 것이 더 나을까요?) "Resolution of rust-lang/ rfcs#2418”은 IIRC Future 트레잇이 최근 안정화되었기 때문에 체크할 수 있습니다.

나는 방금 Reddit 포스트에서 왔고 나는 postfix 구문을 전혀 좋아하지 않는다고 말해야 합니다. 그리고 Reddit의 대다수도 그것을 좋아하지 않는 것 같습니다.

나는 차라리 쓴다

let x = (await future)?

그 이상한 구문을 받아들이는 것보다.

연결에 관해서는 1 await 초과하지 않도록 코드를 리팩토링할 수 있습니다.

또한 미래의 JavaScript는 다음을 수행할 수 있습니다( 스마트 파이프라인 제안 ).

const x = promise
  |> await #
  |> x => x.foo
  |> await #
  |> x => x.bar

await 접두사가 구현되어 있다고 해서 await 를 연결할 수 없다는 의미는 아닙니다.

@KSXGitHub 이것은 실제로 이 토론을 위한 장소가 아니지만 여기에 논리가 설명되어 있으며 많은 사람들이 수개월에 걸쳐 생각한 매우 좋은 이유가 있습니다. https://boats.gitlab.io/blog/post /결정을 기다리다/

@KSXGitHub 최종 구문도 마음에 들지 않지만 #57640, https://internals.rust-lang.org/t/await-syntax-discussion-summary/ , https://internals.rust- 에서 광범위하게 논의되었습니다.

여기에서 디자인 결정에 대해 논의하지 마십시오. 이 명시적인 목적을 위한 스레드가 있습니다.

거기에 댓글을 달 계획이라면 토론이 이미 꽤 진행되었다는 점을 염두에 두시기 바랍니다. 할 말이 있는지 확인하고 스레드에서 이전에 언급되지 않았는지 확인하세요.

@withoutboats 최종 구문은 이미 동의했습니다. 이제 완료로 표시할 때가 되었나요? :붉히다:

7월 4일의 다음 베타 컷에 맞춰 안정화하려는 의도입니까, 아니면 버그를 차단하려면 해결하는 데 또 다른 주기가 필요합니까? A-async-await 태그 아래에는 많은 미해결 문제가 있지만 그 중 얼마나 중요한 문제가 있는지 잘 모르겠습니다.

아, 무시 하세요 . 방금

안녕하십니까! 이 기능의 안정적인 출시를 언제 예상해야 합니까? 그리고 이것을 야간 빌드에서 어떻게 사용할 수 있습니까?

@MehrdadKhnzd https://github.com/rust-lang/rust/issues/62149 에는 목표 릴리스 날짜 등에 대한 정보가 포함되어 있습니다.

async fn 의해 생성된 선물에 대해 Unpin 를 자동으로 구현할 계획이 있습니까?

특히 생성된 Future 코드 자체로 인해 Unpin을 자동으로 사용할 수 없는지 또는 참조를 인수로 사용할 수 있는지 여부가 궁금합니다.

@DoumanAsh async fn에 yield point에서 활성 자체 참조가 없는 경우 생성된 Future가 Unpin을 구현할 수 있다고 생각합니다. 아마도?

"_이_ 차용으로 인해 Unpin 가 아닙니다." + "대안으로 이 미래를 상자에 넣을 수 있습니다"라는 힌트와 함께 꽤 유용한 오류 메시지가 수반되어야 한다고 생각합니다.

#63209의 안정화 PR에는 "모든 차단기가 이제 닫힙니다."라고 기록되어 있습니다. 그리고 8월 20일에 야간에 착륙하여 이번 주 후반에 베타 컷으로 향했습니다. 8월 20일 이후 몇 가지 새로운 차단 문제가 제기되었다는 점은 주목할 가치가 있습니다(AsyncAwait-Blocking 태그로 추적). 이 중 두 개(#63710, #64130)는 실제로 안정화를 방해하지 않는 좋은 것으로 보이지만 논의할 가치가 있는 세 가지 다른 문제(#64391, #64433, #64477)가 있습니다. 이 후자의 세 가지 문제는 관련되어 있으며 모두 AsyncAwait-Blocking 문제 #63832를 해결하기 위해 제출된 PR #64292로 인해 발생합니다. PR #64584는 이미 대부분의 문제를 해결하기 위한 시도에 착수했지만 세 가지 문제는 현재로서는 미해결 상태입니다.

은색은 세 가지 심각한 개방형 차단기 가 컴파일 포인트입니다, 또 다른주기 (위해 야간에 구워한다 결국).

@bstrie 우리는 "높은 우선 순위"로 표시할 더 나은 레이블이 없기 때문에 "AsyncAwait-Blocking"을 재사용하고 있으며 실제로 차단하지 않습니다. 혼동을 줄이기 위해 곧 라벨링 시스템을 개선해야 합니다. @nikomatsakis 참조.

... 좋지 않습니다... 1.38에서 async-await를 놓쳤습니다. 1.39를 기다려야 하는 이유는 몇 가지 "문제"가 포함되지 않았기 때문입니다...

@earthengine 나는 그것이 상황에 대한 공정한 평가라고 생각하지 않습니다. 제기된 문제는 모두 진지하게 고려할 가치가 있습니다. 사람들이 실제로 그것을 사용하려고 시도하는 이러한 문제에 부딪힐 때까지 비동기식으로 착륙하는 것은 좋지 않을 것입니다. :)