Rust: async/प्रतीक्षा के लिए ट्रैकिंग समस्या (RFC 2394)

ऐसा लगता है कि यहां चर्चा समाप्त हो गई है, इसलिए इसे await सिंटैक्स प्रश्न के भाग के रूप में यहां लिंक करना: https://internals.rust-lang.org/t/explicit-future-construction-implicit-await/ 7344

#50307 को क्रियान्वयन रोक दिया गया है।

सिंटैक्स के बारे में: मैं वास्तव में await को साधारण कीवर्ड के रूप में रखना चाहता हूं। उदाहरण के लिए, आइए ब्लॉग से एक चिंता को देखें:

हम निश्चित रूप से निश्चित नहीं हैं कि प्रतीक्षित कीवर्ड के लिए हमें कौन सा सिंटैक्स चाहिए। अगर कुछ परिणाम का भविष्य है - जैसा कि किसी भी आईओ भविष्य के होने की संभावना है - आप इसका इंतजार करने में सक्षम होना चाहते हैं और फिर उस पर ? ऑपरेटर लागू करना चाहते हैं। लेकिन इसे सक्षम करने के लिए प्राथमिकता का क्रम आश्चर्यजनक लग सकता है - await io_future? await पहले और ? सेकंड के बावजूद, ? शाब्दिक रूप से प्रतीक्षा से अधिक कसकर बाध्य होने के बावजूद।

मैं यहां सहमत हूं, लेकिन ब्रेसिज़ खराब हैं। मुझे लगता है कि यह याद रखना आसान है कि ? की प्राथमिकता await से कम है और इसके साथ समाप्त होता है:

let foo = await future?

इसे पढ़ना आसान है, रिफैक्टर करना आसान है। मुझे विश्वास है कि यह बेहतर तरीका है।

let foo = await!(future)?

एक आदेश को बेहतर ढंग से समझने की अनुमति देता है जिसमें संचालन निष्पादित किया जाता है, लेकिन यह कम पठनीय है।

मुझे विश्वास है कि एक बार जब आप उस await foo? को पहले await निष्पादित कर लेते हैं तो आपको इससे कोई समस्या नहीं होती है। यह शायद शाब्दिक रूप से अधिक बंधा हुआ है, लेकिन await बाईं ओर है और ? दाईं ओर है। तो यह अभी भी पर्याप्त तार्किक है await पहले और इसके बाद Result को संभालें।

यदि कोई असहमति है, तो कृपया उन्हें व्यक्त करें ताकि हम चर्चा कर सकें। मुझे समझ में नहीं आता कि चुप डाउनवोट क्या है। हम सभी जंग के लिए शुभकामनाएं देते हैं।

await एक कीवर्ड होने के नाते, @Pzixel पर मेरे विचार मिश्रित हैं। हालांकि यह निश्चित रूप से एक सौंदर्य अपील है, और शायद अधिक सुसंगत है, यह देखते हुए कि async एक कीवर्ड है, किसी भी भाषा में "कीवर्ड ब्लोट" एक वास्तविक चिंता है। उस ने कहा, क्या async बिना await होने का भी कोई मतलब है, सुविधा के अनुसार? अगर ऐसा होता है, तो शायद हम इसे वैसे ही छोड़ सकते हैं। यदि नहीं, तो मैं एक कीवर्ड await बनाने की ओर झुकूंगा।

मुझे लगता है कि यह याद रखना आसान है कि ? की प्राथमिकता await से कम है और इसके साथ समाप्त होता है

इसे सीखना और इसे आंतरिक बनाना संभव हो सकता है, लेकिन एक मजबूत अंतर्ज्ञान है कि जो चीजें छू रही हैं वे सफेद जगहों से अलग चीजों की तुलना में अधिक कसकर बंधे हैं, इसलिए मुझे लगता है कि यह अभ्यास में पहली नज़र में हमेशा गलत पढ़ेगा।

यह सभी मामलों में भी मदद नहीं करता है, उदाहरण के लिए एक फ़ंक्शन जो Result<impl Future, _> :

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

यहां चिंता केवल "क्या आप एकल प्रतीक्षा+ ? की पूर्वता को समझ सकते हैं" नहीं है, बल्कि यह भी है कि "कई प्रतीक्षाओं को श्रृंखलाबद्ध करना कैसा दिखता है।" इसलिए अगर हमने अभी-अभी एक प्राथमिकता चुनी है, तब भी हमें await (await (await first()?).second()?).third()? की समस्या होगी।

await सिंटैक्स के विकल्पों का सारांश, कुछ RFC से और शेष RFC थ्रेड से:

• किसी प्रकार के सीमांकक की आवश्यकता है: await { future }? या await(future)? (यह शोर है)।
• बस एक प्राथमिकता चुनें, ताकि await future? या (await future)? वह करे जो अपेक्षित है (इन दोनों को आश्चर्यजनक लगता है)।
• दो ऑपरेटरों को await? future जैसे कुछ में मिलाएं (यह असामान्य है)।
• किसी तरह await पोस्टफिक्स बनाएं, जैसे future await? या future.await? (यह अभूतपूर्व है)।
• ? तरह एक नए सिगिल का उपयोग करें, जैसा कि future@? (यह "लाइन शोर" है)।
• बिना किसी सिंटैक्स का उपयोग करें, प्रतीक्षित को निहित करना (इससे निलंबन बिंदुओं को देखना कठिन हो जाता है)। इसके लिए काम करने के लिए, भविष्य के निर्माण के कार्य को भी स्पष्ट किया जाना चाहिए। यह मेरे द्वारा ऊपर लिंक किए गए आंतरिक धागे का विषय है।

उस ने कहा, क्या async बिना await होने का भी कोई मतलब है, सुविधा के अनुसार?

@alexreg यह करता है। उदाहरण के लिए, कोटलिन इस तरह से काम करता है। यह "अंतर्निहित प्रतीक्षा" विकल्प है।

@rpjohnst दिलचस्प। खैर, मैं आम तौर पर भाषा की स्पष्ट विशेषताओं के रूप में async और await छोड़ने के लिए हूं, क्योंकि मुझे लगता है कि यह जंग की भावना में अधिक है, लेकिन फिर मैं एसिंक्रोनस प्रोग्रामिंग पर कोई विशेषज्ञ नहीं हूं। ..

@alexreg async/प्रतीक्षा वास्तव में अच्छी सुविधा है, क्योंकि मैं इसके साथ सी # (जो मेरी प्राथमिक भाषा है) में दिन-प्रतिदिन आधार पर काम करता हूं। @rpjohnst ने सभी संभावनाओं को बहुत अच्छी तरह वर्गीकृत किया। मैं दूसरा विकल्प पसंद करता हूं, मैं दूसरों के विचारों (शोर/असामान्य/...) पर सहमत हूं। मैं पिछले 5 वर्षों या कुछ और के लिए async/प्रतीक्षा कोड के साथ काम कर रहा हूं, इस तरह के ध्वज कीवर्ड रखना वाकई महत्वपूर्ण है।

@rpjohnst

तो अगर हमने अभी एक प्राथमिकता चुनी है, तब भी हमें प्रतीक्षा की समस्या होगी (प्रतीक्षा करें (प्रतीक्षा करें (पहले ()?)। दूसरा ()?)। तीसरा ()?।

मेरे अभ्यास में आप कभी भी एक पंक्ति में दो await नहीं लिखते हैं। बहुत ही दुर्लभ मामलों में जब आपको इसकी आवश्यकता होती है तो आप इसे then रूप में फिर से लिखते हैं और प्रतीक्षा का बिल्कुल भी उपयोग नहीं करते हैं। आप स्वयं देख सकते हैं कि पढ़ने की तुलना में इसे पढ़ना कहीं अधिक कठिन है

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# का मौजूदा प्रतीक्षा सिंटैक्स इसे बदसूरत बनाता है?

मुझे लगता है कि सिंटैक्स की परवाह किए बिना यह एक बुरा विचार है क्योंकि प्रति 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 s श्रृंखला के लायक नहीं है, भले ही वाक्यविन्यास इसे अनुमति देता है, क्योंकि यह पूरी तरह से अपठनीय हो जाएगा 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 async अनुरोध बना रहे हैं और फिर उनकी प्रतीक्षा कर रहे हैं। हम प्रत्येक लूप पुनरावृत्ति पर प्रतीक्षा नहीं करते हैं, लेकिन पहले हम async अनुरोधों की एक सरणी बनाते हैं और फिर उन सभी का एक ही बार में इंतजार करते हैं।

मैं कोटलिन को नहीं जानता, इसलिए हो सकता है कि वे इसे किसी तरह सुलझा लें। लेकिन मैं नहीं देखता कि आप इसे कैसे व्यक्त कर सकते हैं यदि "चल रहा है" और "प्रतीक्षा" कार्य समान है।

तो मुझे लगता है कि निहित संस्करण सी # जैसी और भी अधिक निहित भाषाओं में कोई रास्ता नहीं है।
जंग में इसके नियमों के साथ जो आपको u8 को i32 बदलने की अनुमति भी नहीं देता है, यह बहुत अधिक भ्रमित करने वाला होगा।

@Pzixel हाँ, दूसरा विकल्प अधिक बेहतर लोगों में से एक जैसा लगता है। मैंने सी # में भी async/await किया है, लेकिन बहुत अधिक नहीं, क्योंकि मैंने कुछ वर्षों से मुख्य रूप से सी # में प्रोग्राम नहीं किया है। प्राथमिकता के लिए, await (future?) मेरे लिए अधिक स्वाभाविक है।

@rpjohnst मुझे एक पोस्टफिक्स ऑपरेटर का विचार पसंद है, लेकिन मैं पठनीयता और लोगों द्वारा की जाने वाली धारणाओं के बारे में भी चिंतित हूं - यह struct नामक await सदस्य के लिए आसानी से भ्रमित हो सकता है .

कार्य प्रारंभ और कार्य प्रतीक्षा में अंतर करने की संभावना वास्तव में महत्वपूर्ण है।

इसके लायक क्या है, निहित संस्करण ऐसा करता है। यह दोनों आरएफसी सूत्र में और आंतरिक सूत्र में मौत के लिए चर्चा की गई, तो मैं विस्तार का एक बहुत में यहाँ नहीं जाना होगा, लेकिन मूल विचार ही है कि यह कार्य इंतजार से मुखरता ले जाता है काम नहीं करता है यह निर्माण करने के लिए है किसी भी नए निहितार्थ का परिचय न दें।

आपका उदाहरण कुछ इस तरह दिखेगा:

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 async ब्लॉक और join_all / select /etc के अनुरूप हैं।

इसके लायक क्या है, निहित संस्करण ऐसा करता है। यह RFC थ्रेड और इंटर्नल थ्रेड दोनों में मृत्यु के लिए चर्चा की गई थी, इसलिए मैं यहां बहुत अधिक विवरण में नहीं जाऊंगा, लेकिन मूल विचार केवल यह है कि यह कार्य से खोजकर्ता को कार्य निर्माण तक ले जाता है- यह नहीं करता है किसी भी नए निहितार्थ का परिचय न दें।

मुझे विश्वास है कि यह करता है। मैं यहां नहीं देख सकता कि इस फ़ंक्शन में कौन सा प्रवाह होगा, जहां बिंदु है जहां प्रतीक्षा पूरी होने तक निष्पादन टूट जाता है। मुझे केवल async ब्लॉक दिखाई देता है जो कहता है "नमस्ते, यहाँ कहीं async फ़ंक्शन हैं, यह पता लगाने की कोशिश करें कि कौन से हैं, आप आश्चर्यचकित होंगे!"।

एक और बिंदु: जंग एक ऐसी भाषा है जहां आप सब कुछ व्यक्त कर सकते हैं, नंगे धातु के करीब और इसी तरह। मैं कुछ काफी कृत्रिम कोड प्रदान करना चाहता हूं, लेकिन मुझे लगता है कि यह इस विचार को दिखाता है:

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
}

जंग हमेशा क्या हो रहा है पर पूर्ण नियंत्रण प्रदान करती है। await आपको उन बिंदुओं को निर्दिष्ट करने की अनुमति देता है जहां निरंतरता प्रक्रिया होती है। यह आपको भविष्य में unwrap एक मूल्य की भी अनुमति देता है। यदि आप उपयोग पक्ष पर निहित रूपांतरण की अनुमति देते हैं, तो इसके कई निहितार्थ हैं:

1. सबसे पहले, आपको इस व्यवहार का अनुकरण करने के लिए कुछ गंदा कोड लिखना होगा।
2. अब आरएलएस और आईडीई को यह उम्मीद करनी चाहिए कि हमारा मूल्य या तो Future<T> या T प्रतीक्षा कर रहा है। यह कीवर्ड के साथ कोई समस्या नहीं है - यह मौजूद है, तो परिणाम T , अन्यथा यह Future<T>
3. यह कोड को समझने में कठिन बनाता है। आपके उदाहरण में मैं नहीं देखता कि यह get_status_updates लाइन पर निष्पादन को बाधित क्यों करता है, लेकिन यह get_status_update । वे एक दूसरे से काफी मिलते-जुलते हैं। तो यह या तो मूल कोड की तरह काम नहीं करता है या यह इतना जटिल है कि मैं इसे तब भी नहीं देख सकता जब मैं इस विषय से काफी परिचित हूं। दोनों विकल्प इस विकल्प को अनुकूल नहीं बनाते हैं।

मैं यहां नहीं देख सकता कि इस फ़ंक्शन में कौन सा प्रवाह होगा, जहां बिंदु है जहां प्रतीक्षा पूरी होने तक निष्पादन टूट जाता है।

हां, मेरा यही मतलब है "इससे निलंबन बिंदुओं को देखना कठिन हो जाता है।" यदि आप लिंक किए गए आंतरिक धागे को पढ़ते हैं, तो मैंने तर्क दिया कि यह इतनी बड़ी समस्या क्यों नहीं है। आपको कोई नया कोड लिखने की ज़रूरत नहीं है, आप बस एनोटेशन को एक अलग जगह ( await एड एक्सप्रेशन के बजाय async ब्लॉक) में डाल दें। आईडीई को यह बताने में कोई समस्या नहीं है कि किस प्रकार का है (यह हमेशा T फ़ंक्शन कॉल के लिए और Future<Output=T> async ब्लॉक के लिए है)।

मैं यह भी नोट करूंगा कि सिंटैक्स की परवाह किए बिना आपकी समझ शायद गलत है। रस्ट के async फ़ंक्शन किसी भी तरह से प्रतीक्षा किए जाने तक कोई कोड नहीं चलाते हैं, इसलिए आपका b.Status != TaskStatus.RanToCompletion चेक हमेशा पास होगा। आरएफसी थ्रेड में मृत्यु के लिए भी चर्चा की गई थी, यदि आप रुचि रखते हैं कि यह इस तरह क्यों काम करता है।

आपके उदाहरण में मैं नहीं देखता कि यह get_status_updates लाइन पर निष्पादन को बाधित क्यों करता है, लेकिन यह get_status_update । वे एक दूसरे से काफी मिलते-जुलते हैं।

यह दोनों जगहों पर निष्पादन को बाधित async ब्लॉक तब तक नहीं चलते हैं जब तक वे प्रतीक्षा नहीं कर रहे हैं, क्योंकि यह जंग में सभी वायदा के लिए सच है, जैसा कि मैंने ऊपर वर्णित किया है। मेरे उदाहरण में, get_statuses कॉल (और इस तरह इंतजार कर रहा है) get_status_updates , फिर लूप में यह count फ्यूचर्स का निर्माण करता है (लेकिन इंतजार नहीं करता है), फिर यह कॉल करता है (और इस तरह इंतजार कर रहा है) ) join_all , जिस बिंदु पर वे वायदा समवर्ती रूप से कॉल करते हैं (और इस प्रकार प्रतीक्षा करते हैं) get_status_update ।

आपके उदाहरण के साथ एकमात्र अंतर यह है कि जब फ्यूचर्स चलना शुरू होता है- आप में, यह लूप के दौरान होता है; मेरे में, यह join_all । लेकिन यह एक मौलिक हिस्सा है कि रस्ट फ्यूचर्स कैसे काम करता है, इसका अंतर्निहित सिंटैक्स या यहां तक ​​​​कि async / await से कोई लेना-देना नहीं है।

मैं यह भी नोट करूंगा कि सिंटैक्स की परवाह किए बिना आपकी समझ शायद गलत है। Rust के async फ़ंक्शन किसी भी तरह से प्रतीक्षा किए जाने तक कोई कोड नहीं चलाते हैं, इसलिए आपका 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 ब्लॉक के बारे में मिल गया है और जैसा कि मैंने देखा कि वे एक ही जानवर हैं, लेकिन अधिक नुकसान के साथ। मूल प्रस्ताव में प्रत्येक async कार्य को await के साथ जोड़ा जाता है। async ब्लॉक के साथ प्रत्येक कार्य को निर्माण बिंदु पर async ब्लॉक के साथ जोड़ा जाएगा, इसलिए हम लगभग उसी स्थिति में हैं जैसे पहले (1:1 संबंध), लेकिन इससे भी बदतर, क्योंकि ऐसा लगता है अधिक अप्राकृतिक, और समझने में कठिन, क्योंकि कॉलसाइट व्यवहार संदर्भ-निर्भर हो जाता है। प्रतीक्षा के साथ मैं let a = foo() या let b = await foo() हूं और मुझे पता चल जाएगा कि यह कार्य अभी निर्मित या निर्मित और प्रतीक्षित है। अगर मैं let a = foo() साथ async ब्लॉक देखता हूं तो मुझे यह देखना होगा कि क्या ऊपर कुछ 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 }
});

एक और बात जो आपको पूर्ण निहित प्रतीक्षित प्रस्ताव से ध्यान रखनी चाहिए वह यह है कि आप async fn s को गैर- async संदर्भों से कॉल नहीं कर some_function(arg1, arg2, etc) हमेशा some_function के बॉडी को कॉलर के जारी रहने से पहले पूरा करता है, भले ही some_function async । इसलिए async संदर्भ में प्रवेश हमेशा स्पष्ट रूप से चिह्नित किया जाता है, और फ़ंक्शन कॉल सिंटैक्स वास्तव में अधिक सुसंगत होता है।

प्रतीक्षा सिंटैक्स के बारे में: विधि सिंटैक्स वाले मैक्रो के बारे में क्या? मुझे इसकी अनुमति देने के लिए एक वास्तविक 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!()?

स्काला-वर्ल्ड की एक लाइब्रेरी है जो मोनैड रचनाओं को सरल बनाती है: http://monadless.io

हो सकता है कि कुछ विचार रस्ट के लिए दिलचस्प हों।

डॉक्स से उद्धरण:

अधिकांश मुख्यधारा की भाषाओं में एसिंक/प्रतीक्षा मुहावरे का उपयोग करके एसिंक्रोनस प्रोग्रामिंग के लिए समर्थन है या इसे कार्यान्वित कर रहे हैं (उदाहरण के लिए एफ #, सी #/वीबी, जावास्क्रिप्ट, पायथन, स्विफ्ट)। हालांकि उपयोगी, async/प्रतीक्षा आमतौर पर एक विशेष मोनैड से जुड़ा होता है जो एसिंक्रोनस कंप्यूटेशंस (कार्य, भविष्य, आदि) का प्रतिनिधित्व करता है।

यह पुस्तकालय async/प्रतीक्षा के समान समाधान लागू करता है लेकिन किसी भी मोनैड प्रकार के लिए सामान्यीकृत होता है। यह सामान्यीकरण एक प्रमुख कारक है, यह देखते हुए कि कुछ कोडबेस एसिंक्रोनस कंप्यूटेशंस के लिए फ्यूचर के अलावा टास्क जैसे अन्य मोनैड का उपयोग करते हैं।

एक सन्यासी को देखते हुए 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 से मेल खाती है और प्रतीक्षा करने के लिए अनलिफ्ट करें।

यह सामान्य सिंक कोड और क्लोजर के साथ पहले से ही सच है। उदाहरण के लिए:

मुझे यहां कई अंतर दिखाई देते हैं:

1. लैम्ब्डा संदर्भ अपरिहार्य है, लेकिन यह await । await हमारे पास कोई संदर्भ नहीं है, async हमारे पास एक होना चाहिए। पूर्व जीतता है, क्योंकि यह समान सुविधाएँ प्रदान करता है, लेकिन कोड के बारे में कम जानने की आवश्यकता होती है।
2. लैम्ब्डा छोटा होता है, अधिक से अधिक कई रेखाएँ होती हैं इसलिए हम एक ही बार में पूरे शरीर को देखते हैं, और सरल। async फ़ंक्शन काफी बड़े हो सकते हैं (जितना बड़ा, नियमित फ़ंक्शन के रूप में) और जटिल।
3. लैम्ब्डा शायद ही कभी नेस्टेड होते हैं ( then कॉल को छोड़कर, लेकिन इसके लिए await प्रस्तावित है), async ब्लॉक अक्सर नेस्ट किए जाते हैं।

एक और बात जो आपको पूर्ण निहित प्रतीक्षित प्रस्ताव से ध्यान रखनी चाहिए वह यह है कि आप गैर-एसिंक्स संदर्भों से एसिंक्स एफएनएस को कॉल नहीं कर सकते हैं।

हम्म, मैंने उस पर ध्यान नहीं दिया। यह अच्छा नहीं लगता, क्योंकि मेरे अभ्यास में आप अक्सर गैर-एसिंक संदर्भ से एसिंक चलाना चाहते हैं। C# में async सिर्फ एक कीवर्ड है जो कंपाइलर को फंक्शन बॉडी को फिर से लिखने की अनुमति देता है, यह किसी भी तरह से फंक्शन इंटरफेस को प्रभावित नहीं करता है इसलिए async Task<Foo> और Task<Foo> पूरी तरह से विनिमेय हैं, और यह कार्यान्वयन और एपीआई को अलग करता है।

कभी-कभी आप async कार्य को अवरुद्ध करना चाह सकते हैं, उदाहरण के लिए जब आप main से कुछ नेटवर्क API को कॉल करना चाहते हैं। आपको ब्लॉक करना होगा (अन्यथा आप OS पर वापस आ जाते हैं और प्रोग्राम समाप्त हो जाता है) लेकिन आपको async HTTP अनुरोध चलाना होगा। मुझे यकीन नहीं है कि main हैकिंग के अलावा यहां कौन सा समाधान हो सकता है ताकि इसे एसिंक होने की अनुमति मिल सके और साथ ही हम Result मुख्य रिटर्न प्रकार के साथ करते हैं, अगर आप इसे गैर-एसिंक मुख्य से कॉल नहीं कर सकते हैं .

वर्तमान await पक्ष में एक और विचार यह है कि यह अन्य लोकप्रिय भाषा में कैसे काम करता है (जैसा कि @fdietze द्वारा नोट किया

मुझे यहां कई अंतर दिखाई देते हैं

आपको यह भी महसूस करना चाहिए कि मुख्य आरएफसी में पहले से ही async ब्लॉक हैं, उसी शब्दार्थ के साथ निहित संस्करण के रूप में, फिर।

यह अच्छा नहीं लगता, क्योंकि मेरे अभ्यास में आप अक्सर गैर-एसिंक संदर्भ से एसिंक चलाना चाहते हैं।

यह कोई मुद्दा नहीं है। आप अभी भी गैर- async संदर्भों में async ब्लॉक का उपयोग कर सकते हैं (जो ठीक है क्योंकि वे हमेशा की तरह F: Future मूल्यांकन करते हैं), और आप अभी भी वायदा पर स्पॉन या ब्लॉक कर सकते हैं पहले की तरह बिल्कुल उसी एपीआई का उपयोग करना।

आप केवल async fn s पर कॉल नहीं कर सकते हैं, बल्कि उन्हें कॉल को async ब्लॉक में लपेट सकते हैं- जैसा कि आप उस संदर्भ की परवाह किए बिना करते हैं, जिसमें आप हैं, यदि आप F: Future ।

async केवल एक कीवर्ड है जो कंपाइलर को फ़ंक्शन बॉडी को फिर से लिखने की अनुमति देता है, यह किसी भी तरह से फ़ंक्शन इंटरफ़ेस को प्रभावित नहीं करता है

हाँ, यह प्रस्तावों के बीच एक वैध अंतर है। इसे आंतरिक धागे में भी शामिल किया गया था। यकीनन, दोनों के लिए अलग-अलग इंटरफेस होना उपयोगी है क्योंकि यह आपको दिखाता है कि async fn संस्करण निर्माण के हिस्से के रूप में कोई कोड नहीं चलाएगा, जबकि -> impl Future संस्करण उदाहरण के लिए आपको देने से पहले एक अनुरोध शुरू कर सकता है। एक F: Future । यह async fn s को सामान्य fn s के साथ अधिक संगत बनाता है, जिसमें -> T रूप में घोषित कुछ कॉल करने से आपको हमेशा T मिलेगा, भले ही वह async ।

(आपको यह भी ध्यान रखना चाहिए कि रस्ट में अभी भी async fn और Future -रिटर्निंग संस्करण के बीच काफी छलांग है, जैसा कि RFC में वर्णित है। async fn संस्करण का उल्लेख नहीं है Future इसके हस्ताक्षर में कहीं भी; और मैनुअल संस्करण के लिए impl Trait आवश्यकता होती है, जो इसके साथ जीवन भर के लिए कुछ समस्याओं को वहन करता है। यह वास्तव में, async fn लिए प्रेरणा का हिस्सा है।

यह अन्य भाषा जैसे सी #/टाइपस्क्रिप्ट/जेएस/पायथन से माइग्रेट करना आसान बनाता है

यह केवल शाब्दिक await 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 सिंटैक्स के लिए एक फायदा है, await foo / foo await / foo@ / foo.await /... एक ही बात, फर्क सिर्फ इतना है कि आप इसे पहले/बाद में रखते हैं या कीवर्ड के बजाय सिगिल करते हैं।

आपको यह भी ध्यान रखना चाहिए कि रस्ट में अभी भी async fn और फ्यूचर-रिटर्निंग वर्जन के बीच काफी छलांग है, जैसा कि RFC में वर्णित है।

मैं इसे जानता हूं और यह मुझे बहुत परेशान करता है।

और यह एक तोड़ने वाला बदलाव बन जाता है।

आप 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 प्रदान करने की अनुमति देता है। सी # उस पैटर्न से भरा है, उदाहरण के लिए।

खैर, यह उचित लगता है।

हालांकि, मुझे विश्वास है कि इस तरह की निहितता (हम यह नहीं देखते हैं कि foo() यहां एसिंक या सिंक फ़ंक्शन है या नहीं) COM+ जैसे प्रोटोकॉल में उत्पन्न होने वाली समान समस्याओं का कारण बनता है और डब्ल्यूसीएफ को लागू करने का एक कारण था जैसा कि यह था . लोगों को समस्या थी जब एसिंक्स रिमोट अनुरोध सरल तरीकों की कॉल की तरह दिख रहे थे।

यह कोड पूरी तरह से ठीक दिखता है सिवाय इसके कि मैं नहीं देख सकता कि कुछ अनुरोध async या सिंक है या नहीं। मेरा मानना ​​है कि यह महत्वपूर्ण जानकारी है। उदाहरण के लिए:

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 सिंक है या async फ़ंक्शन। मैं अक्सर लूप में मार्कर के रूप में await देखता हूं कि पूरे लोड और प्रदर्शन में बेहतर हासिल करने के लिए इस कोड को बदलना होगा। यह एक कोड है जिसकी मैंने कल समीक्षा की थी (कोड उप-रूपी है, लेकिन यह समीक्षा पुनरावृत्तियों में से एक है):

जैसा कि आप देख सकते हैं, मैंने आसानी से देखा कि हमारे यहां एक लूपिंग प्रतीक्षारत है और मैंने इसे बदलने के लिए कहा। जब परिवर्तन किया गया तो हमें 3x पेज लोड स्पीडअप मिला। await बिना मैं इस दुर्व्यवहार को आसानी से नज़रअंदाज़ कर सकता था।

मैं मानता हूं कि मैंने कोटलिन का उपयोग नहीं किया है, लेकिन पिछली बार जब मैंने उस भाषा को देखा था, तो यह ज्यादातर जावा का एक प्रकार था जिसमें कम वाक्यविन्यास था, उस बिंदु तक जहां यंत्रवत् रूप से एक से दूसरे में अनुवाद करना आसान था। मैं यह भी कल्पना कर सकता हूं कि इसे जावा की दुनिया में क्यों पसंद किया जाएगा (जो थोड़ा वाक्यविन्यास-भारी होता है), और मुझे पता है कि हाल ही में इसे लोकप्रियता में बढ़ावा मिला है, विशेष रूप से जावा नहीं होने के कारण (ओरेकल बनाम Google स्थिति) )

हालांकि, अगर हम लोकप्रियता और परिचित को ध्यान में रखने का फैसला करते हैं, तो हम यह देखना चाहेंगे कि जावास्क्रिप्ट क्या करता है, जो कि स्पष्ट रूप से await ।

उस ने कहा, await को C# द्वारा मुख्यधारा की भाषाओं में पेश किया गया था, जो शायद एक ऐसी भाषा है जहां उपयोगिता को अत्यधिक महत्व माना जाता था। सी # में, एसिंक्रोनस कॉल न केवल await कीवर्ड द्वारा इंगित किए जाते हैं, बल्कि विधि कॉल के Async प्रत्यय द्वारा भी इंगित किए जाते हैं। दूसरी भाषा विशेषता जो await , yield return साथ सबसे अधिक साझा करती है, कोड में भी प्रमुख रूप से दिखाई देती है।

ऐसा क्यों है? मेरा मानना ​​है कि जनरेटर और एसिंक्रोनस कॉल बहुत शक्तिशाली संरचनाएं हैं जो उन्हें कोड में किसी का ध्यान नहीं जाने देती हैं। नियंत्रण प्रवाह ऑपरेटरों का एक पदानुक्रम है:

• बयानों का क्रमिक निष्पादन (अंतर्निहित)
• फ़ंक्शन/विधि कॉल (काफी स्पष्ट, उदाहरण के साथ तुलना करें। Pascal जहां एक नलरी फ़ंक्शन और एक चर के बीच कॉल साइट पर कोई अंतर नहीं है)
• goto (ठीक है, यह एक सख्त पदानुक्रम नहीं है)
• जनरेटर ( yield return बाहर खड़े हो जाते हैं)
• await + Async प्रत्यय

ध्यान दें कि वे अपनी अभिव्यक्ति या शक्ति के अनुसार कम से अधिक क्रिया में कैसे जाते हैं।

बेशक, अन्य भाषाओं ने अलग-अलग तरीके अपनाए। योजना निरंतरता (जैसे call/cc , जो await से बहुत अलग नहीं है) या मैक्रोज़ में यह दिखाने के लिए कोई सिंटैक्स नहीं है कि आप क्या कॉल कर रहे हैं। मैक्रोज़ के लिए, रस्ट ने उन्हें देखना आसान बनाने का तरीका अपनाया।

तो मैं तर्क दूंगा कि कम वाक्यविन्यास अपने आप में वांछनीय नहीं है (इसके लिए एपीएल या पर्ल जैसी भाषाएं हैं), और उस वाक्यविन्यास को केवल बॉयलरप्लेट नहीं होना चाहिए, और पठनीयता में इसकी महत्वपूर्ण भूमिका है।

एक समानांतर तर्क भी है (क्षमा करें, मुझे स्रोत याद नहीं है, लेकिन यह भाषा टीम में किसी से आया हो सकता है) कि लोग नई सुविधाओं के लिए शोर सिंटैक्स के साथ अधिक सहज होते हैं जब वे नए होते हैं, लेकिन फिर ठीक होते हैं कम वर्बोज़ एक एक बार जब वे समाप्त हो जाते हैं तो आमतौर पर उपयोग किए जाते हैं।

await!(foo)? बनाम await foo? के प्रश्न के लिए, मैं पूर्व शिविर में हूं। आप किसी भी वाक्य रचना को बहुत अधिक आंतरिक बना सकते हैं, हालांकि हम रिक्ति और निकटता से संकेत लेने के आदी हैं। await foo? के साथ दो ऑपरेटरों की प्राथमिकता पर खुद को दूसरा अनुमान लगाने का एक लैंग मौका है, जबकि ब्रेसिज़ यह स्पष्ट करते हैं कि क्या हो रहा है। तीन अक्षर सहेजना इसके लायक नहीं है। और जहां तक await! s का पीछा करने की प्रथा है, जबकि यह कुछ भाषाओं में एक लोकप्रिय मुहावरा हो सकता है, मुझे लगता है कि इसमें बहुत अधिक कमियां हैं जैसे खराब पठनीयता और डिबगर्स के साथ बातचीत के लिए अनुकूलन के लायक होना।

तीन अक्षर सहेजना इसके लायक नहीं है।

मेरे वास्तविक अनुभव में, अतिरिक्त वर्ण (जैसे लंबे नाम) कोई समस्या नहीं हैं, लेकिन अतिरिक्त टोकन वास्तव में कष्टप्रद हो सकते हैं। सीपीयू सादृश्य के संदर्भ में, एक लंबा नाम अच्छे इलाके के साथ स्ट्रेटलाइन कोड है - मैं इसे केवल मांसपेशियों की मेमोरी से टाइप कर सकता हूं - जबकि समान संख्या में वर्ण जब इसमें कई टोकन शामिल होते हैं (जैसे विराम चिह्न) शाखायुक्त और कैश मिस से भरा होता है।

(मैं पूरी तरह से सहमत हूं कि await foo? अत्यधिक गैर-स्पष्ट होगा और हमें इससे बचना चाहिए, और अधिक टोकन टाइप करना कहीं अधिक बेहतर होगा; मेरा अवलोकन केवल यह है कि सभी वर्ण समान नहीं बनाए जाते हैं।)

@rpjohnst मुझे लगता है कि आपके वैकल्पिक प्रस्ताव का थोड़ा बेहतर स्वागत हो सकता है यदि इसे "अंतर्निहित प्रतीक्षा" के बजाय "स्पष्ट async" के रूप में प्रस्तुत किया गया हो :-)

यह जानना महत्वपूर्ण है कि bar सिंक या एसिंक फ़ंक्शन है या नहीं।

मुझे यकीन नहीं है कि यह वास्तव में यह जानने से अलग है कि कुछ फ़ंक्शन सस्ता या महंगा है, या यह आईओ करता है या नहीं, या यह किसी वैश्विक स्थिति को छूता है या नहीं। (यह @lnicola के पदानुक्रम पर भी लागू होता

उदाहरण के लिए, यह तथ्य कि कॉल लूप में थी, यदि अधिक नहीं, तो इस तथ्य से महत्वपूर्ण है कि यह async था। और रस्ट में, जहां समानांतरीकरण को सही करना इतना आसान है, आप यह सुझाव भी दे सकते हैं कि महंगे दिखने वाले सिंक्रोनस लूप्स को रेयॉन इटरेटर्स में बदल दिया जाए!

इसलिए मुझे नहीं लगता कि await की आवश्यकता वास्तव में इन अनुकूलन को पकड़ने के लिए महत्वपूर्ण है। ऑप्टिमाइज़ेशन देखने के लिए लूप पहले से ही हमेशा अच्छे स्थान होते हैं, और async fn s पहले से ही एक अच्छा संकेतक है कि आप कुछ सस्ते IO संगामिति प्राप्त कर सकते हैं। यदि आप अपने आप को उन अवसरों से चूकते हुए पाते हैं, तो आप "लूप में async कॉल" के लिए एक क्लीपी लिंट भी लिख सकते हैं जिसे आप कभी-कभी चलाते हैं। सिंक्रोनस कोड के लिए भी समान लिंट होना बहुत अच्छा होगा!

"स्पष्ट async" के लिए प्रेरणा केवल "कम सिंटैक्स" नहीं है, जैसा कि @lnicola का तात्पर्य है। यह फ़ंक्शन कॉल सिंटैक्स के व्यवहार को और अधिक सुसंगत बनाने के लिए है, ताकि foo() हमेशा foo के शरीर को पूरा करने के लिए चलाए। इस प्रस्ताव के तहत, एक एनोटेशन छोड़ने से आपको कम-समवर्ती कोड मिलता है, जो कि वस्तुतः सभी कोड पहले से ही व्यवहार करता है। "स्पष्ट प्रतीक्षा" के अंतर्गत, एक टिप्पणी छोड़ने से आकस्मिक समरूपता, या कम से कम आकस्मिक अंतःक्षेपण का परिचय होता है ,

मुझे लगता है कि आपके वैकल्पिक प्रस्ताव का थोड़ा बेहतर स्वागत हो सकता है यदि इसे "अंतर्निहित प्रतीक्षा" के बजाय "स्पष्ट एसिंक्स" के रूप में प्रस्तुत किया गया हो :-)

धागे को "स्पष्ट भविष्य निर्माण, निहित प्रतीक्षा" नाम दिया गया है, लेकिन ऐसा लगता है कि बाद का नाम अटक गया है। :पी

मुझे यकीन नहीं है कि यह वास्तव में यह जानने से अलग है कि कुछ फ़ंक्शन सस्ता या महंगा है, या यह आईओ करता है या नहीं, या यह किसी वैश्विक स्थिति को छूता है या नहीं। (यह @lnicola के पदानुक्रम पर भी लागू होता

मुझे लगता है कि यह उतना ही महत्वपूर्ण है जितना कि यह जानना कि फ़ंक्शन कुछ राज्य बदलता है, और हमारे पास कॉल साइड दोनों तरफ एक mut कीवर्ड है।

"स्पष्ट async" के लिए प्रेरणा केवल "कम सिंटैक्स" नहीं है, जैसा कि @lnicola का तात्पर्य है। यह फ़ंक्शन कॉल सिंटैक्स के व्यवहार को और अधिक सुसंगत बनाने के लिए है, ताकि foo() हमेशा foo के शरीर को पूरा करने के लिए चलाए।

एक तरफ यह एक अच्छा विचार है। दूसरे पर आप भविष्य के निर्माण और भविष्य के रन को आसानी से अलग कर सकते हैं। मेरा मतलब है कि अगर foo आपको कुछ अमूर्तता देता है जो आपको run पर कॉल करने की अनुमति देता है और कुछ परिणाम प्राप्त करता है तो यह foo बेकार कचरा नहीं बनाता है जो कुछ भी नहीं करता है, यह बहुत कुछ करता है उपयोगी बात: यह कुछ ऐसी वस्तु का निर्माण करता है जिसे आप बाद में विधियों को कॉल कर सकते हैं। यह इसे अलग नहीं बनाता है। जिस foo विधि को हम कॉल करते हैं वह सिर्फ एक ब्लैकबॉक्स है और हम इसके हस्ताक्षर Future<Output=T> और यह वास्तव में भविष्य लौटाता है। इसलिए जब हम ऐसा करना चाहते हैं तो हम इसे स्पष्ट रूप से await करते हैं।

धागे को "स्पष्ट भविष्य निर्माण, निहित प्रतीक्षा" नाम दिया गया है, लेकिन ऐसा लगता है कि बाद का नाम अटक गया है। :पी

मैं व्यक्तिगत रूप से बात करता हूं कि बेहतर विकल्प "स्पष्ट एसिंक स्पष्ट प्रतीक्षा" है :)

पी.एस.

आज रात मुझे भी एक विचार आया: क्या आपने सी # एलडीएम के साथ संवाद करने की कोशिश की? उदाहरण के लिए, @HaloFour , @gafter या @CyrusNajmabadi जैसे लोग। उनसे पूछना वास्तव में अच्छा विचार हो सकता है कि उन्होंने वाक्यविन्यास क्यों लिया। मैं अन्य भाषाओं के लोगों से भी पूछना चाहता हूं लेकिन मैं उन्हें केवल नहीं जानता :) मुझे यकीन है कि मौजूदा वाक्यविन्यास के बारे में उनके पास कई बहसें थीं और वे पहले से ही इस पर बहुत चर्चा कर सकते थे और उनके पास कुछ उपयोगी विचार हो सकते हैं।

इसका मतलब यह नहीं है कि जंग के पास यह वाक्यविन्यास होना चाहिए क्योंकि सी # करता है, लेकिन यह सिर्फ अधिक भारित निर्णय लेने की अनुमति देता है।

मैं व्यक्तिगत रूप से बात करता हूं कि बेहतर विकल्प "स्पष्ट एसिंक स्पष्ट प्रतीक्षा" है :)

मुख्य प्रस्ताव "स्पष्ट एसिंक्स" नहीं है , हालांकि- इसलिए मैंने नाम चुना है। यह " अंतर्निहित एसिंक्स" है, क्योंकि आप एक नज़र में नहीं बता सकते कि एसिंक्रोनस कहां पेश किया जा रहा है। कोई भी गैर-एनोटेटेड फ़ंक्शन कॉल बिना प्रतीक्षा किए भविष्य का निर्माण कर सकता है, भले ही Future इसके हस्ताक्षर में कहीं भी दिखाई न दे।

क्या यह की कीमत के लिए, आंतरिक धागा क्योंकि है कि भविष्य संगत या तो मुख्य विकल्प के साथ है, एक "स्पष्ट async स्पष्ट इंतजार" विकल्प शामिल है। (पहली पोस्ट का अंतिम भाग देखें।)

क्या आपने सी # एलडीएम के साथ संवाद करने की कोशिश की?

मुख्य आरएफसी के लेखक ने किया। जहां तक ​​मुझे याद है, उसमें से जो मुख्य बात सामने आई, वह थी Future को async fn s के हस्ताक्षर में शामिल न करने का निर्णय। C# में, आप Task को अन्य प्रकारों से बदल सकते हैं ताकि फ़ंक्शन को संचालित करने के तरीके पर कुछ नियंत्रण हो सके। लेकिन रस्ट में, हमारे पास ऐसा कोई तंत्र नहीं है (और नहीं होगा)- सभी वायदा एक ही विशेषता से गुजरेंगे, इसलिए उस विशेषता को हर बार लिखने की कोई आवश्यकता नहीं है।

हमने डार्ट भाषा डिजाइनरों के साथ भी संवाद किया, और यह "स्पष्ट एसिंक्स" प्रस्ताव लिखने के लिए मेरी प्रेरणा का एक बड़ा हिस्सा था। डार्ट 1 में एक समस्या थी क्योंकि कॉल किए जाने पर फ़ंक्शन उनके पहले प्रतीक्षा में नहीं चलते थे (रस्ट कैसे काम करता है, लेकिन समान नहीं है), और इससे इतना बड़ा भ्रम पैदा हुआ कि डार्ट 2 में वे बदल गए इसलिए फ़ंक्शन उनके पहले तक चलते हैं बुलाए जाने पर प्रतीक्षा करें। जंग अन्य कारणों से ऐसा नहीं कर सकती है, लेकिन कॉल करने पर यह पूरे कार्य को चला

हमने डार्ट भाषा डिजाइनरों के साथ भी संवाद किया, और यह "स्पष्ट एसिंक्स" प्रस्ताव लिखने के लिए मेरी प्रेरणा का एक बड़ा हिस्सा था। डार्ट 1 में एक समस्या थी क्योंकि कॉल किए जाने पर फ़ंक्शन उनके पहले प्रतीक्षा में नहीं चलते थे (रस्ट कैसे काम करता है, लेकिन समान नहीं है), और इससे इतना बड़ा भ्रम पैदा हुआ कि डार्ट 2 में वे बदल गए इसलिए फ़ंक्शन उनके पहले तक चलते हैं बुलाए जाने पर प्रतीक्षा करें। जंग अन्य कारणों से ऐसा नहीं कर सकती है, लेकिन कॉल करने पर यह पूरे कार्य को चला सकती है, जिससे उस भ्रम से भी बचा जा सकेगा।

बहुत अच्छा अनुभव, मुझे इसकी जानकारी नहीं थी। यह जानकर अच्छा लगा कि आपने इतना बड़ा काम किया है। अच्छा किया

आज रात मुझे भी एक विचार आया: क्या आपने सी # एलडीएम के साथ संवाद करने की कोशिश की? उदाहरण के लिए, @HaloFour , @gafter या @CyrusNajmabadi जैसे लोग। उनसे पूछना वास्तव में अच्छा विचार हो सकता है कि उन्होंने वाक्यविन्यास क्यों लिया।

आपकी रुचि की कोई भी जानकारी प्रदान करने में मुझे खुशी हो रही है। हालांकि, और मैं केवल इसके माध्यम से स्किम्ड हूं। क्या आपके पास वर्तमान में किसी विशिष्ट प्रश्न को संक्षेप में प्रस्तुत करना संभव होगा?

await सिंटैक्स के बारे में (यह पूरी तरह से बेवकूफी भरा हो सकता है, मुझ पर चिल्लाने के लिए स्वतंत्र महसूस करें; मैं एक एसिंक्स प्रोग्रामिंग नोब हूं और मुझे नहीं पता कि मैं किस बारे में बात कर रहा हूं):

"प्रतीक्षा" शब्द का उपयोग करने के बजाय, क्या हम ? समान प्रतीक/ऑपरेटर का परिचय नहीं दे सकते। उदाहरण के लिए, यह # या @ या कुछ और हो सकता है जो वर्तमान में अप्रयुक्त है।

उदाहरण के लिए, यदि यह एक पोस्टफ़िक्स ऑपरेटर था:

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

यह बहुत संक्षिप्त है और स्वाभाविक रूप से बाएं से दाएं पढ़ता है: पहले प्रतीक्षा करें ( # ), फिर त्रुटियों को संभालें ( ? )। यह समस्या नहीं है कि पोस्टफिक्स प्रतीक्षा कीवर्ड में है, जहां .await एक स्ट्रक्चर सदस्य की तरह दिखता है। # स्पष्ट रूप से एक ऑपरेटर है।

मुझे यकीन नहीं है कि पोस्टफिक्स इसके लिए सही जगह है, लेकिन प्राथमिकता के कारण ऐसा लगा। उपसर्ग के रूप में:

let stuff = #func()?;

या बिल्ली भी:

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

क्या इस पर कभी चर्चा हुई है?

(मुझे एहसास है कि इस तरह के "प्रतीकों के यादृच्छिक कीबोर्ड मैश" वाक्यविन्यास से संपर्क करना शुरू हो जाता है कि पर्ल कुख्यात है ... :- डी)

@rayvector https://github.com/rust-lang/rust/issues/50547#issuecomment -388108875, 5वां विकल्प।

@CyrusNajmabadi आने के लिए धन्यवाद। मुख्य प्रश्न यह है कि सूचीबद्ध विकल्पों में से कौन सा विकल्प आपको लगता है कि वर्तमान रस्ट भाषा के रूप में बेहतर है, या शायद कोई अन्य विकल्प है? यह विषय वास्तव में लंबा नहीं है इसलिए आप इसे आसानी से ऊपर से नीचे स्क्रॉल कर सकते हैं। मुख्य प्रश्न: क्या रस्ट को वर्तमान C#/TS/... await तरीके का अनुसरण करना चाहिए या शायद इसे स्वयं लागू करना चाहिए। क्या वर्तमान सिंटैक्स किसी प्रकार की "विरासत" है जिसे आप किसी तरह से बदलना चाहते हैं या यह सी # को सबसे अच्छा फिट बैठता है और यह नई आने वाली भाषाओं के लिए भी सबसे अच्छा विकल्प है?

सी # सिंटैक्स के खिलाफ मुख्य विचार ऑपरेटर प्राथमिकता await foo? पहले इंतजार करना चाहिए और फिर ? ऑपरेटर का मूल्यांकन करना चाहिए और साथ ही अंतर यह है कि सी # निष्पादन के विपरीत कॉलर थ्रेड में पहले 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 मैंने अधिक वर्बोज़ सिंटैक्स के पक्ष में यहाँ थोड़ा तर्क दिया। कारणों में से एक वह है जिसका आप उल्लेख करते हैं:

"रैंडम कीबोर्ड मैश ऑफ़ सिंबल" सिंटैक्स जिसके लिए पर्ल बदनाम है

स्पष्ट करने के लिए, मुझे नहीं लगता कि await!(f)? वास्तव में अंतिम सिंटैक्स के लिए चल रहा है, इसे विशेष रूप से चुना गया था क्योंकि यह किसी विशेष विकल्प के लिए प्रतिबद्ध नहीं होने का एक ठोस तरीका है। यहां सिंटैक्स हैं ( ? ऑपरेटर सहित) जो मुझे लगता है कि अभी भी "चल रहे हैं":

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

या शायद इनमें से कुछ संयोजन। मुद्दा यह है कि उनमें से कई में वरीयता के बारे में स्पष्ट होने के लिए ब्रेसिज़ होते हैं और यहां बहुत सारे विकल्प हैं - लेकिन इरादा यह है कि अंतिम संस्करण में await एक कीवर्ड ऑपरेटर होगा, मैक्रो नहीं ( कुछ बड़े बदलाव को छोड़कर, जैसे कि rpjohnst ने क्या प्रस्तावित किया है)।

मैं या तो एक साधारण पोस्टफिक्स प्रतीक्षित ऑपरेटर (जैसे ~ ) या बिना माता-पिता और उच्चतम प्राथमिकता वाले कीवर्ड के लिए वोट करता हूं।

मैं इस धागे के माध्यम से पढ़ रहा हूं, और मैं निम्नलिखित का प्रस्ताव देना चाहता हूं:

• await f? पहले ? ऑपरेटर का मूल्यांकन करता है, और फिर परिणामी भविष्य की प्रतीक्षा करता है।
• (await f)? पहले भविष्य की प्रतीक्षा करता है, और फिर परिणाम के विरुद्ध ? ऑपरेटर का मूल्यांकन करता है (सामान्य जंग ऑपरेटर प्राथमिकता के कारण)
• await? f `(प्रतीक्षा f)? के लिए वाक्यात्मक चीनी के रूप में उपलब्ध है। मेरा मानना ​​​​है कि "भविष्य में परिणाम लौटाना" एक सुपर आम मामला होगा, इसलिए एक समर्पित वाक्यविन्यास बहुत समझ में आता है।

मैं अन्य टिप्पणीकारों से सहमत हूं कि await स्पष्ट होना चाहिए। जावास्क्रिप्ट में ऐसा करना बहुत दर्द रहित है, और मैं वास्तव में रस्ट कोड की खोज और पठनीयता की सराहना करता हूं, और मुझे लगता है कि एसिंक्स को निहित करने से यह एसिंक कोड के लिए बर्बाद हो जाएगा।

यह मेरे साथ हुआ कि "अंतर्निहित एसिंक ब्लॉक" को proc_macro के रूप में कार्यान्वित किया जाना चाहिए, जो किसी भी भविष्य से पहले केवल await कीवर्ड सम्मिलित करता है।

मुख्य प्रश्न यह है कि सूचीबद्ध विकल्पों में से कौन सा विकल्प आपको लगता है कि वर्तमान रस्ट भाषा के रूप में बेहतर है,

एक सी # डिजाइनर से पूछना कि जंग की भाषा सबसे अच्छी तरह से फिट बैठती है ... दिलचस्प :)

मैं इस तरह का फैसला करने के काबिल महसूस नहीं करता। मुझे जंग पसंद है और इसके साथ खिलवाड़ करना। लेकिन यह ऐसी भाषा नहीं है जिसका मैं दिन-प्रतिदिन उपयोग कर रहा हूं। न ही मैंने इसे अपने मानस में गहराई से समाया है। इस प्रकार, मुझे नहीं लगता कि मैं इस बारे में कोई दावा करने के योग्य हूं कि यहां इस भाषा के लिए उपयुक्त विकल्प क्या हैं। मुझसे गो/टाइपस्क्रिप्ट/सी#/वीबी/सी++ के बारे में पूछना चाहते हैं। ज़रूर, मैं बहुत अधिक सहज महसूस करूँगा। लेकिन इस तरह के किसी भी विचार के साथ सहज महसूस करने के लिए जंग मेरी विशेषज्ञता के दायरे से बहुत अधिक है।

सी # सिंटैक्स के खिलाफ मुख्य विचार ऑपरेटर वरीयता await foo?

यह कुछ ऐसा है जो मुझे लगता है कि मैं इस पर टिप्पणी कर सकता हूं। हमने 'प्रतीक्षा' के साथ वरीयता के बारे में बहुत सोचा और हमने जिस फॉर्म को चाहते थे उसे सेट करने से पहले हमने कई रूपों को आजमाया। हमने पाया कि मुख्य चीजों में से एक यह था कि हमारे लिए, और ग्राहक (आंतरिक और बाहरी) जो इस सुविधा का उपयोग करना चाहते थे, ऐसा शायद ही कभी होता था कि लोग वास्तव में अपने एसिंक कॉल से पहले कुछ भी 'चेन' करना चाहते थे। दूसरे शब्दों में, लोगों को लगता है कि किसी भी पूर्ण-अभिव्यक्ति का सबसे महत्वपूर्ण हिस्सा होने के नाते 'प्रतीक्षा' की ओर दृढ़ता से झुकाव होता है, और इस प्रकार यह शीर्ष के निकट होता है। नोट: 'पूर्ण अभिव्यक्ति' से मेरा मतलब है कि अभिव्यक्ति-कथन के शीर्ष पर आपको जो अभिव्यक्ति मिलती है, या शीर्ष स्तर के असाइनमेंट के दाईं ओर एचटीई अभिव्यक्ति, या अभिव्यक्ति जिसे आप किसी चीज़ के लिए 'तर्क' के रूप में पास करते हैं।

लोगों के लिए एक expr के अंदर 'प्रतीक्षा' के साथ 'जारी रखना' की प्रवृत्ति दुर्लभ थी। हम कभी-कभी (await expr).M() जैसी चीजें देखते हैं, लेकिन वे कम सामान्य लगती हैं और await expr.M() करने वाले लोगों की संख्या से कम वांछनीय लगती हैं।

यही कारण है कि हमने 'प्रतीक्षा' के लिए कोई 'अंतर्निहित' रूप नहीं अपनाया। व्यवहार में यह कुछ ऐसा था जिसके बारे में लोग बहुत स्पष्ट रूप से सोचना चाहते थे, और जिसे वे अपने कोड में फ्रंट-एंड-सेंटर चाहते थे ताकि वे इस पर ध्यान दे सकें। दिलचस्प बात यह है कि सालों बाद भी यह प्रवृत्ति बनी हुई है। यानी कभी-कभी हमें कई सालों बाद पछतावा होता है कि कुछ अत्यधिक क्रियात्मक है। कुछ विशेषताएं उस तरह से शुरू में अच्छी होती हैं, लेकिन एक बार जब लोग इसके साथ सहज हो जाते हैं, तो कुछ terser के साथ बेहतर अनुकूल होते हैं। 'प्रतीक्षा' के साथ ऐसा नहीं हुआ है। लोग अभी भी वास्तव में उस कीवर्ड की भारी-भरकम प्रकृति और हमारे द्वारा चुनी गई प्राथमिकता को पसंद करते हैं।

अब तक, हम अपने दर्शकों के लिए वरीयता पसंद से बहुत खुश हैं। भविष्य में हम यहां कुछ बदलाव कर सकते हैं। लेकिन कुल मिलाकर ऐसा करने का कोई मजबूत दबाव नहीं है।

--

साथ ही अंतर यह है कि सी # निष्पादन के विपरीत कॉलर थ्रेड में पहले प्रतीक्षा तक नहीं चलता है, लेकिन बिल्कुल भी शुरू नहीं होता है, उसी तरह वर्तमान कोड स्निपेट नकारात्मकता जांच नहीं करता है जब तक कि GetEnumerator को पहली बार कॉल नहीं किया जाता है:

आईएमओ, जिस तरह से हमने एन्यूमरेटर्स किया वह कुछ गलती थी और पिछले कुछ वर्षों में भ्रम की स्थिति पैदा हुई है। बहुत सारे कोड इस तरह लिखे जाने की प्रवृत्ति के कारण यह विशेष रूप से खराब रहा है:

```सी#
शून्य कुछ गणनाकर्ता (एक्स तर्क)
{
// मान्य Args, तुल्यकालिक कार्य करें।
कुछ EnumeratorImpl (तर्क) वापस करें;
}

शून्य SomeEnumeratorImpl(X args)
{
//...
उपज
//...
}

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

आप इस विधि को पूरी तरह से कॉल कर सकते हैं और कभी भी प्रतीक्षा नहीं कर सकते। अगर "निष्पादन पहले प्रतीक्षा तक कॉलर थ्रेड में नहीं चलता है" वास्तव में यहां क्या होता है?

प्रतीक्षा करें? f वाक्यात्मक चीनी के रूप में `(प्रतीक्षा f)? के लिए उपलब्ध है। मेरा मानना ​​​​है कि "भविष्य में परिणाम लौटाना" एक सुपर आम मामला होगा, इसलिए एक समर्पित वाक्यविन्यास बहुत समझ में आता है।

यह मेरे साथ सबसे अधिक प्रतिध्वनित होता है। यह 'प्रतीक्षा' को सर्वोच्च अवधारणा होने की अनुमति देता है, लेकिन परिणाम प्रकारों के सरल संचालन की भी अनुमति देता है।

सी # से हम एक बात जानते हैं कि प्राथमिकता के आसपास लोगों की अंतर्ज्ञान सफेद जगह से बंधी हुई है। तो अगर आपके पास "एक्स का इंतजार है?" तो यह तुरंत महसूस होता है कि await की प्राथमिकता ? से कम है क्योंकि ? अभिव्यक्ति को समाप्त कर देता है। यदि उपरोक्त को वास्तव में (await x)? रूप में पार्स किया जाता है तो यह हमारे दर्शकों के लिए आश्चर्यजनक होगा।

इसे await (x?) रूप में पार्स करना सिंटैक्स से सबसे स्वाभाविक लगेगा, और भविष्य/कार्य का 'परिणाम' प्राप्त करने की आवश्यकता को पूरा करेगा, और 'प्रतीक्षा' करना चाहता है कि यदि आपको वास्तव में एक मूल्य प्राप्त हुआ है . यदि वह फिर एक परिणाम वापस लौटाता है, तो यह संकेत देने के लिए 'प्रतीक्षा' के साथ संयुक्त होना उचित लगता है कि यह बाद में होता है। इसलिए await? x? प्रत्येक ? कोड के उस हिस्से से कसकर बांधता है जिससे यह सबसे स्वाभाविक रूप से संबंधित है। पहला ? await (और विशेष रूप से इसका परिणाम) से संबंधित है, और दूसरा x ।

अगर "निष्पादन पहले प्रतीक्षा तक कॉलर थ्रेड में नहीं चलता है" वास्तव में यहां क्या होता है?

जब तक फोन करने वाले की वापसी मान इंतजार कर रहा है कुछ नहीं होता FooAsync , इसके बाद से FooAsync के शरीर रन तक या तो एक await या वापस करती है।

यह इस तरह से काम करता है क्योंकि Rust Future s पोल-चालित, स्टैक-आवंटित, और poll पहली कॉल के बाद अचल हैं। कॉल करने वाले के पास उन्हें स्थान पर ले जाने का मौका होना चाहिए - शीर्ष स्तर के लिए ढेर पर Future s, या फिर माता-पिता के अंदर उप-मूल्य Future , अक्सर "स्टैक फ्रेम" पर किसी भी कोड को निष्पादित करने से पहले async fn कॉल करना।

इसका मतलब है कि हम या तो a) C# जनरेटर-जैसे शब्दार्थ के साथ फंस गए हैं, जहां कोई कोड आह्वान पर नहीं चलता है, या b) कोटलिन कोरआउटिन-जैसे शब्दार्थ, जहां फ़ंक्शन को कॉल करना भी तुरंत और निहित रूप से इसकी प्रतीक्षा करता है (क्लोजर-जैसे async { .. } ब्लॉक जब आपको समवर्ती निष्पादन की आवश्यकता होती है)।

मैं उत्तरार्द्ध का पक्ष लेता हूं, क्योंकि यह सी # जेनरेटर के साथ आपके द्वारा उल्लिखित समस्या से बचाता है, और ऑपरेटर प्राथमिकता प्रश्न से पूरी तरह से बचाता है।

@CyrusNajmabadi Rust में, Future आमतौर पर तब तक कोई काम नहीं करता जब तक कि इसे Task रूप में नहीं बनाया जाता है (यह F# Async ):

let bar = foo();

इस मामले में foo() रिटर्न एक Future , लेकिन यह शायद वास्तव में कुछ भी नहीं करता है। आपको इसे मैन्युअल रूप से स्पॉन करना होगा (जो कि F# Async ):

tokio::run(bar);

जब इसे स्पॉन किया जाता है, तो यह Future चलाएगा। चूंकि यह Future का डिफ़ॉल्ट व्यवहार है, नहीं चलाने के लिए अधिक सुसंगत होगा जब तक कि यह उत्पन्न न हो जाए।

स्पष्ट रूप से सी # में स्थिति अलग है, क्योंकि सी # में जब आप foo() कॉल करते हैं तो यह तुरंत Task चलना शुरू कर देता है, इसलिए पहले await तक कोड चलाने के लिए सी # में यह समझ में आता है। .

इसके अलावा ... चीजें कैसे काम करती हैं अगर आपके पास ऐसा कुछ है [...] आप पूरी तरह से इस विधि को कॉल कर सकते हैं और कभी भी प्रतीक्षा नहीं कर सकते हैं। अगर "निष्पादन पहले प्रतीक्षा तक कॉलर थ्रेड में नहीं चलता है" वास्तव में यहां क्या होता है?

यदि आप FooAsync() कॉल करते हैं तो यह कुछ नहीं करता है, कोई कोड नहीं चलाया जाता है। फिर जब आप इसे स्पॉन करते हैं, तो यह कोड को समकालिक रूप से चलाएगा, await कभी नहीं चलेगा, और इसलिए यह तुरंत () लौटाता है (जो कि रस्ट का void का संस्करण है)

दूसरे शब्दों में, यह "निष्पादन कॉलर थ्रेड में पहली प्रतीक्षा तक नहीं चलता है", यह "निष्पादन तब तक नहीं चलता जब तक कि यह स्पष्ट रूप से उत्पन्न न हो (जैसे tokio::run )"

तब तक कुछ नहीं होता जब तक कॉलर FooAsync के रिटर्न वैल्यू का इंतजार नहीं करता, जिस बिंदु पर FooAsync का शरीर तब तक चलता है जब तक कि प्रतीक्षा या वापस नहीं आ जाती।

इक यह दुर्भाग्यपूर्ण लगता है। कई बार ऐसा होता है कि मैं कभी किसी चीज़ का इंतज़ार नहीं कर पाता (अक्सर रद्द करने और कार्यों के साथ संयोजन के कारण)। एक देव के रूप में मैं अभी भी उन शुरुआती त्रुटियों की सराहना करता हूं (जो सबसे आम कारणों में से एक है जो लोग निष्पादन को प्रतीक्षा करने के लिए चलाना चाहते हैं)।

इसका मतलब है कि हम या तो a) C# जनरेटर-जैसे शब्दार्थ के साथ फंस गए हैं, जहां कोई कोड आह्वान पर नहीं चलता है, या b) कोटलिन कोरआउटिन-जैसे शब्दार्थ, जहां फ़ंक्शन को कॉल करना भी तुरंत और निहित रूप से इसका इंतजार करता है (क्लोजर-जैसे async { के साथ। . } ब्लॉक जब आपको समवर्ती निष्पादन की आवश्यकता होती है)।

इन्हें देखते हुए, मैं बाद वाले की तुलना में पूर्व को अधिक पसंद करूंगा। हालांकि बस मेरी निजी पसंद है। यदि आपके डोमेन के लिए कोटलिन दृष्टिकोण अधिक स्वाभाविक लगता है, तो उसके लिए जाएं!

@CyrusNajmabadi Ick। यह दुर्भाग्यपूर्ण लगता है। कई बार ऐसा होता है कि मैं कभी किसी चीज़ का इंतज़ार नहीं कर पाता (अक्सर रद्द करने और कार्यों के साथ संयोजन के कारण)। एक देव के रूप में मैं अभी भी उन शुरुआती त्रुटियों की सराहना करता हूं (जो सबसे आम कारणों में से एक है जो लोग निष्पादन को प्रतीक्षा करने के लिए चलाना चाहते हैं)।

मैं इसके ठीक विपरीत महसूस करता हूं। जावास्क्रिप्ट के साथ मेरे अनुभव में await का उपयोग करना भूल जाना बहुत आम है। उस स्थिति में Promise अभी भी चलेगा, लेकिन त्रुटियों को निगल लिया जाएगा (या अन्य अजीब चीजें होती हैं)।

जंग/हास्केल/एफ# शैली के साथ, या तो Future चलता है (सही त्रुटि प्रबंधन के साथ), या यह बिल्कुल नहीं चलता है। फिर आप देखते हैं कि यह नहीं चल रहा है, इसलिए आप इसकी जांच करें और इसे ठीक करें। मेरा मानना ​​​​है कि इसका परिणाम अधिक मजबूत कोड में होता है।

@Pauan @rpjohnst स्पष्टीकरण के लिए धन्यवाद। वे दृष्टिकोण थे जिन पर हमने भी विचार किया। लेकिन यह वास्तव में व्यवहार में उतना वांछनीय नहीं निकला।

उन मामलों में जहां आप नहीं चाहते थे कि यह "वास्तव में कुछ भी करें। आपको इसे मैन्युअल रूप से स्पॉन करना होगा", हमने इसे मॉडल के लिए क्लीनर पाया कि मांग पर कार्यों को उत्पन्न करने वाली किसी चीज़ को वापस करने के रूप में। यानी Func<Task> जितना आसान कुछ।

मैं इसके ठीक विपरीत महसूस करता हूं। जावास्क्रिप्ट के साथ मेरे अनुभव में प्रतीक्षा का उपयोग करना भूल जाना बहुत आम है।

सी # यह सुनिश्चित करने के लिए काम करता है कि आपने या तो प्रतीक्षा की है, या अन्यथा समझदारी से कार्य का उपयोग किया है।

लेकिन त्रुटियों को निगल लिया जाएगा

मैं जो कह रहा हूं, वह इसके विपरीत है। मैं कह रहा हूं कि मैं कोड को उत्सुकता से निष्पादित करना चाहता हूं ताकि त्रुटियां ऐसी चीजें हों जिन्हें मैं तुरंत हिट करता हूं, भले ही मैं कार्य में कोड निष्पादित करने के लिए कभी भी समाप्त नहीं हो पाता। यह पुनरावृत्तियों के साथ समान है। मैं बहुत कुछ जानता हूं कि मैं उस समय गलत बना रहा था जब मैं फ़ंक्शन को कॉल करता हूं और संभावित रूप से लाइन के नीचे बहुत अधिक होता है यदि इटरेटर स्ट्रीम किया जाता है।

फिर आप देखते हैं कि यह नहीं चल रहा है, इसलिए आप इसकी जांच करें और इसे ठीक करें।

जिन परिदृश्यों में मैं बात कर रहा हूं, "नहीं चल रहा है" पूरी तरह से उचित है। आखिरकार, मेरा आवेदन किसी भी समय यह तय कर सकता है कि उसे वास्तव में कार्य चलाने की आवश्यकता नहीं है। वह बग नहीं है जिसका मैं वर्णन कर रहा हूं। मैं जिस बग का वर्णन कर रहा हूं वह यह है कि मैंने सत्यापन पास नहीं किया है, और मैं उस बिंदु के करीब के बारे में जानना चाहता हूं जहां मैंने तार्किक रूप से उस बिंदु के विपरीत काम बनाया है जब काम को वास्तव में चलाने की आवश्यकता होती है। यह देखते हुए कि ये एसिंक प्रसंस्करण का वर्णन करने के लिए मॉडल हैं, यह अक्सर एक दूसरे से बहुत दूर होने के मामले में जाना जाता है। इसलिए जितनी जल्दी हो सके मुद्दों के बारे में जानकारी होना मूल्यवान है।

जैसा कि उल्लेख किया गया है, यह भी काल्पनिक नहीं है। ऐसा ही कुछ धाराओं/पुनरावृत्तियों के साथ होता है। लोग अक्सर उन्हें बनाते हैं, लेकिन बाद में उन्हें महसूस नहीं करते। लोगों के लिए इन चीजों को उनके स्रोत तक वापस ट्रैक करना एक अतिरिक्त बोझ रहा है। यही कारण है कि इतने सारे एपीआई (एचटीई बीसीएल सहित) को अब सिंक्रोनस/शुरुआती काम और वास्तविक आस्थगित/आलसी काम के बीच विभाजन करना पड़ता है।

मैं जो कह रहा हूं, वह इसके विपरीत है। मैं कह रहा हूं कि मैं कोड को उत्सुकता से निष्पादित करना चाहता हूं ताकि त्रुटियां ऐसी चीजें हों जिन्हें मैं तुरंत हिट करता हूं, भले ही मैं कार्य में कोड निष्पादित करने के लिए कभी भी समाप्त नहीं हो पाता।

मैं शुरुआती त्रुटियों की इच्छा को समझ सकता हूं, लेकिन मैं उलझन में हूं: किस स्थिति में आप कभी भी " Future को पैदा करने के लिए इधर-उधर नहीं हो पाएंगे"?

रस्ट में जिस तरह से Future s काम करता है, वह यह है कि आप Future s को एक साथ विभिन्न तरीकों से (async/wait सहित, समानांतर कॉम्बिनेटर सहित, आदि) बनाते हैं, और ऐसा करने से यह एक बनाता है सिंगल फ्यूज्ड Future जिसमें सभी उप- Future s शामिल हैं। और फिर अपने प्रोग्राम के शीर्ष-स्तर पर ( main ) फिर आप इसे स्पॉन करने के लिए tokio::run (या समान) का उपयोग करते हैं।

उस एकल tokio::run कॉल के अलावा main , आप आमतौर पर मैन्युअल रूप से Future s नहीं पैदा करेंगे, इसके बजाय आप बस उन्हें लिखें। और रचना स्वाभाविक रूप से स्पॉनिंग/त्रुटि प्रबंधन/रद्दीकरण/आदि को संभालती है। सही ढंग से।

मैं भी कुछ स्पष्ट करना चाहता हूँ। जब मैं कुछ ऐसा कहता हूं:

लेकिन यह वास्तव में व्यवहार में उतना वांछनीय नहीं निकला।

मैं विशेष रूप से हमारी भाषा/मंच के साथ चीजों के बारे में बात कर रहा हूं। मैं केवल उन निर्णयों में अंतर्दृष्टि दे सकता हूं जो सी #/नेट/कोरएफएक्स इत्यादि के लिए समझ में आते हैं। यह पूरी तरह से मामला हो सकता है कि आपकी स्थिति अलग है और आप किसके लिए अनुकूलित करना चाहते हैं और आपको किस प्रकार के दृष्टिकोणों को पूरी तरह से जाना चाहिए अलग दिशा।

मैं शुरुआती त्रुटियों की इच्छा को समझ सकता हूं, लेकिन मैं उलझन में हूं: किस स्थिति में आप कभी भी "भविष्य को जन्म देने के लिए इधर-उधर नहीं हो पाएंगे"?

सभी समय :)

विचार करें कि कैसे रोसलिन (सी #/वीबी कंपाइलर/आईडीई कोडबेस) स्वयं लिखा गया है। यह भारी async और इंटरैक्टिव है । यानी इसके लिए प्राथमिक उपयोग का मामला साझा फैशन में उपयोग किया जाना है, जिसमें कई क्लाइंट इसे एक्सेस कर रहे हैं। क्लायस्ट सेवाएं उपयोगकर्ता के साथ सुविधाओं की एक संपत्ति पर आम बातचीत कर रही हैं, जिनमें से कई निर्णय लेते हैं कि उपयोगकर्ता को किसी भी प्रकार की कार्रवाइयां करने के कारण मूल रूप से महत्वपूर्ण कार्य करने की आवश्यकता नहीं है। उदाहरण के लिए, जैसा कि उपयोगकर्ता टाइप कर रहा है, हम कई कार्य रचनाएं और जोड़तोड़ कर रहे हैं, और हम उन्हें निष्पादित करने के लिए इधर-उधर नहीं जाने का फैसला कर सकते हैं क्योंकि एक और घटना कुछ एमएस बाद में आई थी।

उदाहरण के लिए, जैसा कि उपयोगकर्ता टाइप कर रहा है, हम कई कार्य रचनाएं और जोड़तोड़ कर रहे हैं, और हम उन्हें निष्पादित करने के लिए इधर-उधर नहीं जाने का फैसला कर सकते हैं क्योंकि एक और घटना कुछ एमएस बाद में आई थी।

क्या यह सिर्फ रद्दीकरण द्वारा नियंत्रित नहीं है, यद्यपि?

और रचना स्वाभाविक रूप से स्पॉनिंग/त्रुटि प्रबंधन/रद्दीकरण/आदि को संभालती है। सही ढंग से।

ऐसा लगता है कि चीजों का प्रतिनिधित्व करने के लिए हमारे पास दो बहुत अलग मॉडल हैं। यह ठीक है :) मेरी व्याख्याओं को हमारे द्वारा चुने गए मॉडल के संदर्भ में लिया जाना है। हो सकता है कि वे आपके द्वारा चुने जा रहे मॉडल के लिए कोई मतलब न रखें।

ऐसा लगता है कि चीजों का प्रतिनिधित्व करने के लिए हमारे पास दो बहुत अलग मॉडल हैं। यह ठीक है :) मेरी व्याख्याओं को हमारे द्वारा चुने गए मॉडल के संदर्भ में लिया जाना है। हो सकता है कि वे आपके द्वारा चुने जा रहे मॉडल के लिए कोई मतलब न रखें।

बिल्कुल, मैं सिर्फ आपके नजरिए को समझने की कोशिश कर रहा हूं, और अपने नजरिए को भी समझा रहा हूं। चीजों को समझाने के लिए समय निकालने के लिए धन्यवाद।

क्या यह सिर्फ रद्दीकरण द्वारा नियंत्रित नहीं है, यद्यपि?

रद्दीकरण अतुल्यकालिक (हमारे लिए) के लिए एक ऑर्थोगोनल अवधारणा है। वे आमतौर पर एक साथ उपयोग किए जाते हैं। लेकिन न तो दूसरे की जरूरत है।

आपके पास पूरी तरह से रद्दीकरण के बिना एक प्रणाली हो सकती है, और यह केवल इतना मामला हो सकता है कि आप कभी भी उस कोड को चलाने के लिए तैयार नहीं होते हैं जो आपके द्वारा बनाए गए कार्यों का 'इंतजार' करता है। यानी तार्किक कारण से आपका कोड बस जा सकता है "मुझे 'टी' की प्रतीक्षा करने की आवश्यकता नहीं है, मैं बस कुछ और करने जा रहा हूं"। कार्यों के बारे में कुछ भी (हमारी दुनिया में) यह निर्देश या आवश्यकता नहीं है कि यह अपेक्षा की जानी चाहिए कि उस कार्य की प्रतीक्षा की जानी चाहिए। ऐसी प्रणाली में, मैं शीघ्र सत्यापन प्राप्त करना चाहूंगा।

नोट: यह इटरेटर समस्या के समान है। आप अपने कोड में बाद में उपयोग करने का इरादा परिणाम प्राप्त करने के लिए किसी को कॉल कर सकते हैं। हालांकि, कई कारणों से, आपको वास्तव में परिणामों का उपयोग करने की आवश्यकता नहीं हो सकती है। मेरी व्यक्तिगत इच्छा अभी भी सत्यापन परिणाम जल्दी प्राप्त करने की होगी, भले ही मैं तकनीकी रूप से उन्हें प्राप्त नहीं कर पाता और मेरा कार्यक्रम सफल होता।

मुझे लगता है कि दोनों दिशाओं के लिए उचित तर्क हैं। लेकिन मेरा मानना ​​है कि समकालिक दृष्टिकोण में विपक्ष की तुलना में अधिक लाभ हैं। बेशक, यदि एचटीई सिंक्रोनस दृष्टिकोण सचमुच फिट नहीं होता है कि आपका वास्तविक इम्प्लांट कैसे काम करना चाहता है तो ऐसा लगता है कि आपको क्या करना है, इस सवाल का जवाब देना प्रतीत होता है: डी

दूसरे शब्दों में, मुझे नहीं लगता कि आपका दृष्टिकोण यहां खराब है। और अगर इस मॉडल के आसपास इसके मजबूत लाभ हैं, तो आपको लगता है कि यह जंग के लिए सही है, तो इसके लिए जाएं :)

आपके पास पूरी तरह से रद्दीकरण के बिना एक प्रणाली हो सकती है, और यह केवल इतना मामला हो सकता है कि आप कभी भी उस कोड को चलाने के लिए तैयार नहीं होते हैं जो आपके द्वारा बनाए गए कार्यों का 'इंतजार' करता है। यानी तार्किक कारण से आपका कोड बस जा सकता है "मुझे 'टी' की प्रतीक्षा करने की आवश्यकता नहीं है, मैं बस कुछ और करने जा रहा हूं"।

व्यक्तिगत रूप से, मुझे लगता है कि सामान्य if/then/else तर्क द्वारा इसे सबसे अच्छा संभाला जाता है:

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

लेकिन जैसा कि आप कहते हैं, यह सी # से बिल्कुल अलग परिप्रेक्ष्य है।

व्यक्तिगत रूप से, मुझे लगता है कि अगर/फिर/अन्य तर्क सामान्य रूप से सबसे अच्छा संभाला जाता है:

हां। यह ठीक होगा यदि स्थिति की जाँच उसी बिंदु पर की जा सकती है जिस बिंदु पर कार्य बनाया गया है (और कई मामले इस तरह हैं)। लेकिन हमारी दुनिया में आमतौर पर ऐसा नहीं है कि चीजें इतनी अच्छी तरह से जुड़ी हुई हैं। आखिरकार, हम उपयोगकर्ताओं के जवाब में उत्सुकता से async कार्य करना चाहते हैं (ताकि आवश्यकता पड़ने पर परिणाम तैयार हों), लेकिन हम बाद में निर्णय ले सकते हैं कि हमें अब और परवाह नहीं है।

हमारे डोमेन में 'प्रतीक्षा' उस बिंदु पर होता है जब व्यक्ति को "मूल्य की आवश्यकता होती है", जो एक अलग निर्धारण/घटक/आदि है। "क्या मुझे मूल्य पर काम करना शुरू करना चाहिए?"

एक मायने में, ये बहुत अलग हैं, और इसे एक गुण के रूप में देखा जाता है। निर्माता और उपभोक्ता की पूरी तरह से अलग नीतियां हो सकती हैं, लेकिन 'टास्क' के अच्छे सार के माध्यम से किए जा रहे एसिंक्स कार्य के बारे में प्रभावी ढंग से संवाद कर सकते हैं।

वैसे भी, मैं सिंक/एसिंक्स राय से वापस आ जाऊंगा। स्पष्ट रूप से यहां खेलने के लिए बहुत अलग मॉडल हैं। :)

प्राथमिकता के संदर्भ में मैंने कुछ जानकारी दी है कि सी # चीजों के बारे में कैसे सोचता है। मुझे आशा है कि यह मददगार है। अगर आपको वहां कोई और जानकारी चाहिए तो मुझे बताएं।

@CyrusNajmabadi हां, आपकी अंतर्दृष्टि काफी मददगार थी। व्यक्तिगत रूप से मैं आपसे सहमत हूं कि await? foo जाने का रास्ता है (हालांकि मुझे "स्पष्ट async " प्रस्ताव भी पसंद है)।

BTW, यदि आप मॉडलिंग async/सिंक कार्य के आसपास .net मॉडल की सभी पेचीदगियों और उस सिस्टम के सभी पेशेवरों/विपक्षों पर सर्वश्रेष्ठ विशेषज्ञ राय चाहते हैं, तो @stephentoub बात करने वाला व्यक्ति होगा। वह चीजों को समझाने, पेशेवरों/विपक्षों को स्पष्ट करने, और दोनों पक्षों के मॉडल में गहराई से गोता लगाने में सक्षम होने के कारण मुझसे लगभग 100 गुना बेहतर होगा। वह यहां .net के दृष्टिकोण से अच्छी तरह परिचित हैं (इसमें किए गए विकल्प और अस्वीकार किए गए विकल्प शामिल हैं), और शुरुआत से ही इसे कैसे विकसित करना पड़ा है। वह उन दृष्टिकोणों की पूर्ण लागतों के बारे में भी दर्दनाक रूप से अवगत है जो नेट ने लिया है (जो एचटीई कारणों में से एक है, जो अब वैल्यू टास्क मौजूद है), जो मुझे लगता है कि कुछ ऐसा होगा जो आप लोग शून्य/कम की इच्छा के साथ सबसे पहले और सबसे महत्वपूर्ण सोच रहे हैं -कॉस्ट एब्स्ट्रैक्शन।

मुझे याद है, शुरुआती दिनों में इन विभाजनों के बारे में समान विचार .net के दृष्टिकोण में रखे गए थे, और मुझे लगता है कि वह अंतिम निर्णयों के बारे में बहुत अच्छी तरह से बोल सकते थे और वे कितने उपयुक्त थे।

मैं अभी भी await? future पक्ष में वोट करूंगा, भले ही यह थोड़ा अपरिचित लग रहा हो। क्या इनकी रचना करने में कोई वास्तविक कमी है?

यहाँ ठंड (F#) बनाम गर्म (C#,JS) asyncs के पेशेवरों और विपक्षों का एक और गहन विश्लेषण है: http://tomasp.net/blog/async-csharp-differences.aspx

पोस्टफ़िक्स मैक्रोज़ के लिए अब एक नया RFC है जो एक समर्पित सिंटैक्स परिवर्तन के बिना पोस्टफ़िक्स await साथ प्रयोग की अनुमति देगा: 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();

मैं उस async पैटर्न को await तुलना में कॉल करना पसंद करता हूं, हालांकि मुझे इसे पैटर्न सिंटैक्स बनाने का अधिक लाभ नहीं दिखता है। पैटर्न सिंटैक्स आम तौर पर उनके अभिव्यक्ति समकक्षों के संबंध में दोहरी रूप से काम करते हैं।

https://doc.rust-lang.org/nightly/std/task/index.html के वर्तमान पृष्ठ के अनुसार, कार्य मोड में libcore से reexports और liballoc के लिए reexports दोनों शामिल हैं, जो परिणाम को थोड़ा सा बनाता है ... उप-इष्टतम। आशा है कि स्थिर होने से पहले इसे किसी तरह संबोधित किया जाएगा।

मैंने कोड पर एक नज़र डाली। और मेरे पास कुछ सुझाव हैं:

• [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 उपयोग करना चाहिए जहां यह लागू होता है

मैं इस सामान के लिए एक पीआर भी प्रदान कर सकता हूं। @cramertj @aturon विवरण पर चर्चा करने के लिए डिस्कॉर्ड के माध्यम से मुझसे संपर्क करने के लिए स्वतंत्र महसूस करें।

सभी 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 नियमित विधि की तरह काम नहीं करता है। वास्तव में, विचार करें कि await विधि क्या करेगी जब async ब्लॉक/फ़ंक्शन में न हो। तरीके नहीं जानते कि उन्हें किस संदर्भ में निष्पादित किया गया है, इसलिए यह संकलन त्रुटि का कारण नहीं बन सका।

@xfix यह सामान्य रूप से सच नहीं है। कंपाइलर जो कुछ भी करना चाहता है वह कर सकता है और इस मामले में विशेष रूप से विधि कॉल को संभाल सकता है। विधि शैली कॉल वरीयता समस्या हल करती है लेकिन यह अप्रत्याशित है (प्रतीक्षा अन्य भाषाओं में इस तरह काम नहीं करती है) और शायद संकलक में एक बदसूरत हैक होगा।

@elszben संकलक जो कुछ भी यह चाहता है इसका मतलब यह नहीं है कि यह करना चाहिए जो कुछ भी यह चाहता है क्या कर सकते हैं यही कारण है कि।

future.await() एक नियमित फ़ंक्शन कॉल की तरह लगता है, जबकि ऐसा नहीं है। यदि आप इस तरह से जाना चाहते हैं, तो ऊपर कहीं प्रस्तावित future.await!() सिंटैक्स समान शब्दार्थ की अनुमति देगा, और एक मैक्रो के साथ स्पष्ट रूप से चिह्नित करेगा "यहां कुछ अजीब चल रहा है, मुझे पता है।"

संपादित करें: पोस्ट हटा दी गई

मैंने इस पोस्ट को फ्यूचर्स RFC में स्थानांतरित कर दिया है। संपर्क

क्या किसी ने async fn और #[must_use] के बीच की बातचीत को देखा है?

यदि आपके पास async fn , तो इसे सीधे कॉल करने से कोई कोड नहीं चलता है और Future लौटाता है; ऐसा लगता है कि सभी async fn में "बाहरी" impl Future प्रकार पर एक अंतर्निहित #[must_use] async fn होना चाहिए, इसलिए आप Future साथ कुछ किए बिना उन्हें कॉल नहीं कर सकते हैं।

इसके शीर्ष पर, यदि आप #[must_use] को async fn स्वयं संलग्न करते हैं, तो ऐसा लगता है कि आंतरिक फ़ंक्शन की वापसी पर लागू होना चाहिए। इसलिए, यदि आप #[must_use] async fn foo() -> T { ... } लिखते हैं, तो आप प्रतीक्षा के परिणाम के साथ कुछ किए बिना await!(foo()) नहीं लिख सकते।

क्या किसी ने async fn और #[must_use] के बीच की बातचीत को देखा है?

इस चर्चा में रुचि रखने वाले अन्य लोगों के लिए, https://github.com/rust-lang/rust/issues/51560 देखें।

मैं इस बारे में सोच रहा था कि कैसे अतुल्यकालिक कार्यों को लागू किया जाता है और महसूस किया जाता है कि ये कार्य पुनरावर्तन, या पारस्परिक पुनरावर्तन का समर्थन नहीं करते हैं।

प्रतीक्षा सिंटैक्स के लिए, मैं व्यक्तिगत रूप से पोस्ट-फिक्स मैक्रोज़ की ओर हूं, इसकी आसान श्रृंखला के लिए कोई अंतर्निहित प्रतीक्षा दृष्टिकोण नहीं है, और इसे एक विधि कॉल की तरह भी इस्तेमाल किया जा सकता है

@warlord500 आप ऊपर वर्णित लाखों डेवलपर्स की संपूर्ण await की श्रृंखला नहीं बनाना चाहते हैं।

@Pzixel कृपया यह न
मुझे पता है कि कुछ योगदानकर्ता चेनिंग प्रतीक्षा की अनुमति नहीं देना चाहते हैं, लेकिन हम में से कुछ हैं
डेवलपर्स जो करते हैं। मुझे यकीन नहीं है कि आपको यह धारणा भी कहाँ से मिली कि मैं अनदेखा कर रहा हूँ
डेवलपर्स की राय, मेरी टिप्पणी केवल समुदाय के सदस्य की राय और उस राय को रखने के मेरे कारणों को निर्दिष्ट कर रही थी।

संपादित करें : यदि आपकी राय में मतभेद है तो कृपया साझा करें! मैं उत्सुक हूं कि आप ऐसा क्यों कहते हैं
हमें सिंटैक्स जैसी विधि के माध्यम से प्रतीक्षा करने की अनुमति नहीं देनी चाहिए?

@warlord500 क्योंकि MS टीम ने अपने अनुभव को हज़ारों ग्राहकों और लाखों डेवलपर्स के बीच साझा किया। मैं इसे स्वयं जानता हूं क्योंकि मैं दिन-प्रतिदिन के आधार पर async/प्रतीक्षा कोड लिखता हूं, और आप उन्हें कभी भी श्रृंखलाबद्ध नहीं करना चाहते हैं। यहाँ सटीक उद्धरण है, यदि आप चाहें:

हमने 'प्रतीक्षा' के साथ वरीयता के बारे में बहुत सोचा और हमने जिस फॉर्म को चाहते थे उसे सेट करने से पहले हमने कई रूपों को आजमाया। हमने पाया कि मुख्य चीजों में से एक यह था कि हमारे लिए, और ग्राहक (आंतरिक और बाहरी) जो इस सुविधा का उपयोग करना चाहते थे, ऐसा शायद ही कभी होता था कि लोग वास्तव में अपने एसिंक कॉल से पहले कुछ भी 'चेन' करना चाहते थे। दूसरे शब्दों में, लोगों को लगता है कि किसी भी पूर्ण-अभिव्यक्ति का सबसे महत्वपूर्ण हिस्सा होने के नाते 'प्रतीक्षा' की ओर दृढ़ता से झुकाव होता है, और इस प्रकार यह शीर्ष के निकट होता है। नोट: 'पूर्ण अभिव्यक्ति' से मेरा मतलब है कि अभिव्यक्ति-कथन के शीर्ष पर आपको जो अभिव्यक्ति मिलती है, या शीर्ष स्तर के असाइनमेंट के दाईं ओर एचटीई अभिव्यक्ति, या अभिव्यक्ति जिसे आप किसी चीज़ के लिए 'तर्क' के रूप में पास करते हैं।

लोगों के लिए एक expr के अंदर 'प्रतीक्षा' के साथ 'जारी रखना' की प्रवृत्ति दुर्लभ थी। हम कभी-कभी (await expr).M() जैसी चीजें देखते हैं, लेकिन वे कम आम लगती हैं और await expr.M() करने वाले लोगों की तुलना में कम वांछनीय लगती हैं।

मैं अब काफी उलझन में हूं, अगर मैं आपको सही ढंग से समझता हूं, तो हमें समर्थन नहीं करना चाहिए
पोस्ट-फिक्स आसान श्रृंखला शैली का इंतजार करें क्योंकि इसका आमतौर पर उपयोग नहीं किया जाता है? आप प्रतीक्षा को अभिव्यक्ति के सबसे महत्वपूर्ण भाग के रूप में देखते हैं।
मैं इस मामले में केवल यह सुनिश्चित करने के लिए मानता हूं कि मैं आपको सही ढंग से समझता हूं।
अगर मैं गलत हूं तो मुझे सुधारने में संकोच न करें।

इसके अलावा, आप कृपया उस लिंक को पोस्ट कर सकते हैं जहां आपको उद्धरण मिला है,
शुक्रिया।

उपरोक्त दो बिंदुओं के लिए मेरा काउंटर सिर्फ इसलिए है क्योंकि आप आमतौर पर कुछ का उपयोग नहीं करते हैं, इसका मतलब यह नहीं है कि इसका समर्थन करना उस मामले के लिए हानिकारक होगा जहां यह कोड क्लीनर बनाता है।

कभी-कभी प्रतीक्षा करें अभिव्यक्ति के सबसे महत्वपूर्ण भाग में, यदि भविष्य उत्पन्न करने वाली अभिव्यक्ति है
सबसे महत्वपूर्ण हिस्सा है और आप इसे शीर्ष पर रखना चाहते हैं, आप अभी भी ऐसा कर सकते हैं यदि हम सामान्य मैक्रो शैली के अतिरिक्त पोस्टफिक्स मैक्रो शैली की अनुमति देते हैं

इसके अलावा, आप कृपया उस लिंक को पोस्ट कर सकते हैं जहां आपको उद्धरण मिला है,
शुक्रिया।

लेकिन... लेकिन आपने कहा कि आपने पूरा सूत्र पढ़ लिया...

लेकिन मुझे इसे साझा करने में कोई समस्या नहीं है: https://github.com/rust-lang/rust/issues/50547#issuecomment -388939886। मेरा सुझाव है कि आप सभी साइरस पोस्ट पढ़ें, यह वास्तव में पूरे C#/.Net पारिस्थितिकी तंत्र का अनुभव है, यह एक अमूल्य अनुभव है जिसे रस्ट द्वारा पुन: उपयोग किया जा सकता है।

कभी-कभी अभिव्यक्ति के सबसे महत्वपूर्ण भाग की प्रतीक्षा करें

उद्धरण स्पष्ट रूप से विपरीत कहता है और आप जानते हैं, मुझे खुद भी ऐसा ही लग रहा है, दिन-प्रतिदिन के आधार पर async/प्रतीक्षा करना।

क्या आपके पास async/प्रतीक्षा का अनुभव है? क्या आप इसे साझा कर सकते हैं, कृपया?

वाह, मुझे विश्वास नहीं हो रहा है कि मैं चूक गया। इसे लिंक करने के लिए अपने दिन में से समय निकालने के लिए धन्यवाद।
मेरे पास कोई अनुभव नहीं है इसलिए मुझे लगता है कि भव्य योजना में मेरी राय इतनी मायने नहीं रखती

@Pzixel मैं async / await का उपयोग करके अपने और दूसरों के अनुभव के बारे में जानकारी साझा करने की सराहना करता हूं, लेकिन कृपया अन्य योगदानकर्ताओं का सम्मान करें। अपने स्वयं के तकनीकी बिंदुओं को सुनने के लिए आपको दूसरों के अनुभव स्तरों की आलोचना करने की आवश्यकता नहीं है।

मॉडरेटर नोट: @Pzixel समुदाय के सदस्यों पर व्यक्तिगत हमलों की अनुमति नहीं है। मैंने इसे आपकी टिप्पणी से संपादित किया है। ऐसा फिर से मत करना। यदि हमारी मॉडरेशन नीति के बारे में आपके कोई प्रश्न हैं, तो कृपया हमारे साथ [email protected] पर

@crabtw मैंने किसी की भी आलोचना नहीं की। यहां होने वाली किसी भी असुविधा के लिए मुझे खेद है।

मैंने एक बार समाप्ति के बारे में पूछा था जब मैं यह समझना चाहता था कि क्या व्यक्ति को 'वेट' का पीछा करने की वास्तविक आवश्यकता है या यह उसकी आज की विशेषताओं का एक्सट्रपलेशन है। मैं प्राधिकरण से अपील नहीं करना चाहता था, यह केवल जानकारी का एक उपयोगी समूह है जहां मैं कह सकता हूं "आपको इसे स्वयं आज़माने और इस सच्चाई को स्वयं महसूस करने की आवश्यकता है"। यहां कुछ भी आपत्तिजनक नहीं है।

समुदाय के सदस्यों पर व्यक्तिगत हमलों की अनुमति नहीं है। मैंने इसे आपकी टिप्पणी से संपादित किया है।

कोई व्यक्तिगत हमला नहीं। जैसा कि मैं देख सकता हूं कि आपने डाउनवोट्स के बारे में मेरे संदर्भ पर टिप्पणी की। खैर, मेरे पोस्ट डाउनवोट पर यह सिर्फ मेरा रिएक्टर था, कुछ खास नहीं। चूंकि इसे हटा दिया गया था, इसलिए उस संदर्भ को हटाना भी उचित है (यह आगे के पाठकों के लिए भी भ्रमित करने वाला हो सकता है), इसलिए इसे हटाने के लिए धन्यवाद।

संदर्भ के लिए धन्यवाद। मैं यह उल्लेख करना चाहता था कि आप 'सुसमाचार' के रूप में जो कुछ भी कहते हैं, उसमें से कोई भी नहीं लेना चाहिए :) जंग और सी # अलग-अलग समुदायों, प्रतिमानों और मुहावरों के साथ अलग-अलग भाषाएं हैं। आपको अपनी भाषा के लिए सबसे अच्छा विकल्प चुनना चाहिए। मुझे उम्मीद है कि मेरे शब्द मददगार हैं और अंतर्दृष्टि दे सकते हैं। लेकिन चीजों को करने के अलग-अलग तरीकों के लिए हमेशा खुले रहें।

मेरी आशा है कि आप रस्ट के लिए कुछ अद्भुत लेकर आएंगे। फिर हम देख सकते हैं कि आपने क्या किया और सी # के लिए इसे कृपापूर्वक चोरी कर लिया :)

जहाँ तक मेरा बता सकते हैं, लिंक किए गए तर्क मुख्य रूप से की पूर्वता बारे में बात करती await , और विशेष रूप से तर्क है कि यह पार्स करने के लिए समझ में आता है await x.y() के रूप में await (x.y()) बजाय (await x).y() क्योंकि उपयोगकर्ता अधिक बार पूर्व व्याख्या चाहता है और अपेक्षा करता है (और रिक्ति भी उस व्याख्या का सुझाव देती है)। और मैं सहमत हूं, हालांकि मैं यह भी देखूंगा कि await!(x.y()) जैसे सिंटैक्स अस्पष्टता को हटा देता है।

हालांकि, मुझे नहीं लगता कि x.y().await!().z() जैसे चेनिंग के मूल्य के संबंध में कोई विशेष उत्तर सुझाता है।

उद्धृत टिप्पणी भाग में दिलचस्प है क्योंकि रस्ट में एक बड़ा अंतर है, जो हमारे अंतिम प्रतीक्षा सिंटैक्स को समझने में देरी करने वाले बड़े कारकों में से एक रहा है: सी # में कोई ? ऑपरेटर नहीं है, इसलिए उनके पास कोई कोड नहीं है (await expr)? । वे (await expr).M() को वास्तव में असामान्य बताते हैं, और मुझे लगता है कि यह जंग में भी सच होगा, लेकिन मेरे दृष्टिकोण से इसका एकमात्र अपवाद ? , जो बहुत सामान्य होगा क्योंकि कई फ़्यूचर्स परिणामों का मूल्यांकन करेंगे (उदाहरण के लिए, वे सभी जो अभी मौजूद हैं, करते हैं)।

@withboats हाँ, यह सही है। मैं इस भाग को एक बार फिर उद्धृत करना चाहता हूं:

मेरे दृष्टिकोण से इसका एकमात्र अपवाद है ?

यदि केवल अपवाद है तो await? foo को (await foo)? शॉर्टकट के रूप में बनाना और दोनों दुनिया के सर्वश्रेष्ठ होने के लिए उचित लगता है।

अभी, कम से कम, के प्रस्तावित वाक्य रचना await!() के स्पष्ट उपयोग की अनुमति देगा ? । हम await और ? के संयोजन के लिए कुछ छोटे सिंटैक्स के बारे में चिंता कर सकते हैं यदि और जब हम await लिए बेस सिंटैक्स को बदलने का निर्णय लेते हैं। (और क्या हम इसे करने के लिए बदल के आधार पर, हम सब पर एक मुद्दा नहीं हो सकता।)

@joshtriplett ये अतिरिक्त ब्रेसिज़ अस्पष्टता को दूर करते हैं, लेकिन वे वास्तव में बहुत भारी हैं। उदाहरण के लिए मेरे वर्तमान प्रोजेक्ट में खोजें:

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

मेरे पास 2743 स्लॉट में 139 प्रतीक्षारत हैं। शायद यह कोई बड़ी बात नहीं है, लेकिन मुझे लगता है कि हमें ब्रेसलेस विकल्प को क्लीनर और बेहतर मानना ​​चाहिए। कहा जा रहा है, ? एकमात्र अपवाद है, इसलिए हम ब्रेसिज़ के बिना आसानी से await foo उपयोग कर सकते हैं, और इस विशेष मामले के लिए एक विशेष सिंटैक्स पेश कर सकते हैं। यह कोई बड़ी बात नहीं है, लेकिन LISP प्रोजेक्ट के लिए कुछ ब्रेसिज़ बचा सकते हैं।

मैंने एक ब्लॉग पोस्ट बनाया है कि मुझे क्यों लगता है कि एसिंक फ़ंक्शंस को उनके हस्ताक्षर के लिए बाहरी रिटर्न प्रकार दृष्टिकोण का उपयोग करना चाहिए। मन लगाकर पढ़ाई करो!

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

मैंने सभी चर्चाओं का पालन नहीं किया है, इसलिए बेझिझक मुझे बताएं कि अगर मैं इसे याद नहीं करता तो इस पर पहले ही चर्चा हो चुकी होती।

आंतरिक वापसी प्रकार दृष्टिकोण के बारे में यहां एक अतिरिक्त चिंता है: Stream s के लिए वाक्यविन्यास कैसा दिखता है, जब इसे निर्दिष्ट किया जाएगा? मुझे लगता है कि async fn foo() -> impl Stream<Item = T> अच्छा लगेगा और async fn foo() -> impl Future<Output = T> अनुरूप होगा, लेकिन यह आंतरिक रिटर्न प्रकार दृष्टिकोण के साथ काम नहीं करेगा। और मुझे नहीं लगता कि हम एक async_stream कीवर्ड पेश करना चाहेंगे।

@Ekleog Stream को एक अलग कीवर्ड का उपयोग करने की आवश्यकता होगी। यह async उपयोग नहीं कर सकता क्योंकि impl Trait इसके विपरीत काम करता है। यह केवल यह सुनिश्चित कर सकता है कि कुछ लक्षण लागू किए गए हैं, लेकिन लक्षणों को पहले से ही अंतर्निहित ठोस प्रकार पर लागू करने की आवश्यकता है।

हालाँकि, बाहरी रिटर्न प्रकार का दृष्टिकोण काम में आएगा यदि हम एक दिन async जनरेटर फ़ंक्शन जोड़ना चाहते हैं:

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

Stream Return = () साथ सभी async जनरेटर के लिए लागू किया जा सकता है। यह इसे संभव बनाता है:

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

नोट: जेनरेटर पहले से ही रात में हैं, लेकिन वे इस सिंटैक्स का उपयोग नहीं करते हैं। फ्यूचर्स 0.3 में Stream विपरीत वर्तमान में पिनिंग-अवेयर नहीं हैं।

संपादित करें: इस कोड ने पहले Generator । मुझे Stream और Generator बीच अंतर याद आया। धाराएँ अतुल्यकालिक हैं। इसका मतलब यह है कि उन्हें कोई मूल्य नहीं देना पड़ सकता है। वे या तो Poll::Ready या Poll::Pending साथ जवाब दे सकते हैं। दूसरी ओर Generator को हमेशा समकालिक रूप से उपज या पूर्ण करना होता है। इसे दर्शाने के लिए मैंने अब इसे AsyncGenerator बदल दिया है।

Edit2: @Ekleog जनरेटर का वर्तमान कार्यान्वयन मार्कर के बिना एक सिंटैक्स का उपयोग करता है और ऐसा लगता है कि यह शरीर के अंदर yield तलाश करके एक जनरेटर होना चाहिए। इसका मतलब है कि आप यह कहने में सही होंगे कि async का पुन: उपयोग किया जा सकता है। क्या वह दृष्टिकोण समझदार है, हालाँकि यह एक और सवाल है। लेकिन मुझे लगता है कि यह किसी अन्य विषय के लिए है ^^'

वास्तव में, मैं सोच रहा था कि async का पुन: उपयोग किया जा सकता है, क्या यह केवल इसलिए होगा क्योंकि async इस RFC के अनुसार, केवल Future s के साथ अनुमत होगा, और इस प्रकार पता लगा सकता है यह रिटर्न प्रकार को देखकर Stream उत्पन्न कर रहा है (जो या तो Future या Stream )।

अब मैं इसे क्यों उठा रहा हूं इसका कारण यह है कि यदि हम Future s और Stream s दोनों उत्पन्न करने के लिए समान async कीवर्ड रखना चाहते हैं, तो मुझे लगता है कि बाहरी रिटर्न टाइप दृष्टिकोण अधिक साफ होगा, क्योंकि यह स्पष्ट होगा, और मुझे नहीं लगता कि कोई भी उम्मीद करेगा कि async fn foo() -> i32 i32 की एक धारा उत्पन्न करेगा (जो संभव होगा यदि शरीर निहित हो एक yield और आंतरिक वापसी प्रकार दृष्टिकोण चुना गया था)।

हमारे पास जेनरेटर के लिए दूसरा कीवर्ड हो सकता है (उदाहरण के लिए gen fn ), और फिर दोनों को लागू करके स्ट्रीम बनाएं (उदाहरण के लिए async gen fn )। बाहरी रिटर्न प्रकार को इसमें आने की आवश्यकता नहीं है।

@rpjohnst मैं इसे लाया क्योंकि बाहरी रिटर्न प्रकार दृष्टिकोण आसानी से दो संबंधित प्रकारों को सेट करना संभव बनाता है।

हम दो संबद्ध प्रकार सेट नहीं करना चाहते हैं। एक स्ट्रीम अभी भी केवल एक ही प्रकार है, impl Iterator<Item=impl Future>> या ऐसा कुछ भी नहीं।

@rpjohnst मेरा मतलब संबंधित प्रकार Yield और Return (async) जनरेटर से था

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 द्वारा प्रस्तावित फीचर के साथ अनुभव की आवश्यकता है, यह देखने के लिए कि क्या री-वेटिंग की आवश्यकता है।

मैं आपके साथ पूरी तरह से सहमत होना चाहता हूं, लेकिन बस आश्चर्य है: अगर मैं आपकी टिप्पणी को सही ढंग से पढ़ता हूं, तो एसिंक/प्रतीक्षा वाक्यविन्यास का स्थिरीकरण एसिंक धाराओं के लिए एक सभ्य वाक्यविन्यास और कार्यान्वयन की प्रतीक्षा करेगा, और उन दोनों के साथ अनुभव प्राप्त करने के लिए? (जैसा कि एक बार स्थिर होने के बाद बाहरी रिटर्न प्रकारों और आंतरिक रिटर्न प्रकारों के बीच बदलना संभव नहीं होगा)

मैंने सोचा था कि जंग 2018 के लिए एसिंक/प्रतीक्षा की उम्मीद थी और तब तक एसिंक जेनरेटर तैयार होने की उम्मीद नहीं होगी, लेकिन ...?

(इसके अलावा, मेरी टिप्पणी केवल @MajorBreakfast के ब्लॉग पोस्ट के लिए एक अतिरिक्त तर्क के रूप में थी, फिर भी ऐसा प्रतीत होता है कि इस विषय पर चर्चा पूरी तरह से मिटा दी गई है … यह ब्लॉग पोस्ट?)

प्रतीक्षित कीवर्ड का संकीर्ण उपयोग मामला अभी भी मुझे भ्रमित करता है। (Esp। फ्यूचर बनाम स्ट्रीम बनाम जेनरेटर)

क्या एक उपज कीवर्ड सभी उपयोग के मामलों के लिए पर्याप्त नहीं होगा? के रूप में

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

जो रिटर्न प्रकार को स्पष्ट रखता है और इसलिए सभी "निरंतरता" आधारित शब्दार्थों के लिए केवल एक कीवर्ड की आवश्यकता होती है, बिना कीवर्ड और लाइब्रेरी को एक साथ बहुत कसकर।

(हमने इसे मिट्टी की भाषा बीटीडब्ल्यू में किया था)

@aep await एक भविष्य उपज नहीं है generator-- से यह के निष्पादन रुक जाता है Future और रिटर्न कॉलर को नियंत्रित करते हैं।

@cramerj अच्छी तरह से यह कर सकता था कि वास्तव में (एक भविष्य लौटाएं जिसमें उपज कीवर्ड के बाद निरंतरता शामिल हो), जो कि एक व्यापक उपयोग केस है।
लेकिन मुझे लगता है कि मुझे उस चर्चा के लिए पार्टी में थोड़ी देर हो गई है? :)

@aep एक await -विशिष्ट कीवर्ड के लिए तर्क भविष्य के जनरेटर-विशिष्ट yield कीवर्ड के साथ कंपोज़िबिलिटी के लिए है। हम एसिंक जेनरेटर का समर्थन करना चाहते हैं और इसका मतलब है कि दो स्वतंत्र निरंतरता "स्कोप"।

इसके अलावा, यह भविष्य को वापस नहीं कर सकता है जिसमें निरंतरता शामिल है, क्योंकि जंग वायदा मतदान-आधारित हैं, कॉलबैक-आधारित नहीं, कम से कम आंशिक रूप से स्मृति प्रबंधन कारणों से। किसी एक वस्तु को बदलने के लिए poll लिए yield की तुलना में इसके संदर्भों को इधर-उधर फेंकना बहुत आसान है।

मुझे लगता है कि एसिंक/प्रतीक्षा भाषा को प्रदूषित करने का एक कीवर्ड कारण नहीं होना चाहिए, क्योंकि एसिंक सिर्फ एक विशेषता है जो भाषा की आंतरिक नहीं है।

@sackery यह भाषा के आंतरिक भाग का हिस्सा है, और इसे पूरी तरह से पुस्तकालय के रूप में लागू नहीं किया जा सकता है।

तो बस इसे निम की तरह कीवर्ड के रूप में बनाएं, सी # करता है!

प्रश्न: async नॉन-मूव क्लोजर के हस्ताक्षर क्या होने चाहिए जो परस्पर संदर्भ द्वारा मूल्यों को कैप्चर करते हैं? वर्तमान में वे सिर्फ एकमुश्त प्रतिबंधित हैं। ऐसा लगता है कि हम किसी प्रकार का GAT दृष्टिकोण चाहते हैं जो बंद होने के उधार को भविष्य के मृत होने तक चलने की अनुमति देगा, उदाहरण के लिए:

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

@cramertj एक बंद होने के कब्जे वाले वातावरण में परिवर्तनीय संदर्भों को वापस करने के साथ यहां एक सामान्य समस्या है। संभवतः समाधान को async fn से बंधे रहने की आवश्यकता नहीं है?

@ बिना नाव के सही, यह async स्थितियों में कहीं अधिक सामान्य होने जा रहा है, शायद यह कहीं और होगा।

कैसे के बारे में fn async के बजाय async fn ?
मुझे 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 s के फ़ंक्शन पॉइंटर्स और भविष्य लौटाने वाले अन्य फ़ंक्शन समान ° हैं। यहाँ एक खेल का
• pub fn की खोज में unsafe या const फ़ंक्शन नहीं मिलेंगे।

° async fn द्वारा लौटाया गया ठोस प्रकार निश्चित रूप से अज्ञात है। मेरा मतलब है कि वे दोनों एक प्रकार लौटाते हैं जो Future

@xmeta ध्यान दें कि mut "देने के बाद नहीं जाता", या यों कहें कि 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 async ब्लॉक से वापस आता है-- यदि हम return को बिल्कुल भी अनुमति देते हैं, तो यह वास्तव में एकमात्र संभव विकल्प है। हम return पर पूरी तरह से प्रतिबंध लगा सकते हैं और async ब्लॉक से लौटने के लिए 'label: async { .... break 'label x; } जैसी किसी चीज़ का उपयोग कर सकते हैं। यह इस बातचीत में भी शामिल है कि ब्रेक-टू-ब्लॉक सुविधा के लिए कीवर्ड break या return का उपयोग करना है या नहीं (https://github.com/rust-lang/rust/issues/ 48594)।

मैं return अनुमति देने के लिए हूं। इसे मना करने की मुख्य चिंता यह है कि यह भ्रमित करने वाला हो सकता है क्योंकि यह वर्तमान फ़ंक्शन से नहीं, बल्कि async ब्लॉक से वापस आता है। हालांकि, मुझे संदेह है कि यह भ्रमित करने वाला होगा। क्लोजर पहले से ही return अनुमति देता है और मैंने इसे कभी भी भ्रमित करने वाला नहीं पाया। सीखना कि return एसिंक्स ब्लॉक पर भी लागू होता है आईएमओ आसान है और इसे आईएमओ काफी मूल्यवान है।

@cramertj return हमेशा युक्त फ़ंक्शन से बाहर निकलना चाहिए, कभी भी आंतरिक ब्लॉक नहीं; अगर यह काम करने के लिए समझ में नहीं आता है, जो ऐसा लगता है जैसे यह नहीं करता है, तो return बिल्कुल भी काम नहीं करना चाहिए।

इसके लिए break का उपयोग करना दुर्भाग्यपूर्ण लगता है, लेकिन यह देखते हुए कि दुर्भाग्य से हमारे पास लेबल-ब्रेक-वैल्यू है, तो यह कम से कम उसके अनुरूप है।

क्या एसिंक्स मूव्स और क्लोजर अभी भी योजनाबद्ध हैं? निम्नलिखित आरएफसी से है:

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

और आगे पृष्ठ के नीचे

async { /* body */ }

// is equivalent to

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

जो return को क्लोजर के साथ संरेखित करता है, और पिक-अप और व्याख्या करना काफी आसान लगता है।

क्या ब्रेक-टू-ब्लॉक rfc किसी लेबल के साथ आंतरिक क्लोजर से बाहर निकलने की अनुमति देने की योजना बना रहा है? यदि नहीं (और मैं यह सुझाव नहीं दे रहा हूं कि इसे इसकी अनुमति देनी चाहिए), तो returns के सुसंगत व्यवहार को अस्वीकार करना बहुत दुर्भाग्यपूर्ण होगा, फिर एक ऐसे विकल्प का उपयोग करें जो ब्रेक-टू-ब्लॉक के rfc के साथ असंगत भी हो।

@memoryruins async || { ... return x; ... } बिल्कुल काम करना चाहिए। मैं कह रहा हूं कि async { ... return x; ... } नहीं होना चाहिए, ठीक इसलिए क्योंकि async बंद नहीं है। return का एक बहुत ही विशिष्ट अर्थ है: "युक्त फ़ंक्शन से वापसी"। क्लोजर एक फ़ंक्शन है। async ब्लॉक नहीं हैं।

@memoryruins वे दोनों पहले ही लागू हो चुके हैं।

@joshtriplett

async ब्लॉक नहीं हैं।

मुझे लगता है कि मैं अभी भी समझ में कार्य के रूप में उनके बारे में लगता है कि वे ब्लॉक उन जिसमें से एक अलग से परिभाषित निष्पादन संदर्भ के साथ एक शरीर है, इसलिए यह मेरे लिए समझ में आता है कि return करने के लिए आंतरिक है async ब्लॉक। यहां भ्रम ज्यादातर वाक्य-विन्यास लगता है, उस ब्लॉक में आमतौर पर केवल एक अभिव्यक्ति के लिए रैपर होते हैं जो कोड को एक नए निष्पादन संदर्भ में लाते हैं जैसे || और async करते हैं।

हालांकि, @cramertj "वाक्यविन्यास" महत्वपूर्ण है।

इस तरह से इसके बारे में सोचो। यदि आपके पास ऐसा कुछ है जो फ़ंक्शन की तरह नहीं दिखता है (या बंद करने की तरह, और आप कार्यों के रूप में बंद को पहचानने के लिए उपयोग किए जाते हैं), और आपको return , तो आपका मानसिक पार्सर कहां जाता है?

return को हाईजैक करने वाली कोई भी चीज़ किसी और के कोड को पढ़ने में अधिक भ्रमित करती है। लोग कम से कम इस विचार के अभ्यस्त हैं कि break कुछ मूल ब्लॉक में वापस आ जाता है और उन्हें यह जानने के लिए संदर्भ पढ़ना होगा कि कौन सा ब्लॉक है। return हमेशा बड़ा हथौड़ा रहा है जो पूरे समारोह से लौटता है।

अगर उन्हें तत्काल मूल्यांकन बंद करने के समान व्यवहार नहीं किया जा रहा है, तो मैं मानता हूं कि वापसी असंगत होगी, खासकर वाक्य रचनात्मक रूप से। यदि ? एसिंक ब्लॉक में पहले से ही तय किया जा चुका है (आरएफसी अभी भी कहता है कि यह अनिश्चित था), तो मुझे लगता है कि इसे इसके साथ गठबंधन किया जाएगा।

@joshtriplett यह कहना मेरे लिए मनमाना लगता है कि आप "रिटर्न स्कोप" के रूप में फ़ंक्शंस और क्लोजर (जो वाक्य रचनात्मक रूप से बहुत अलग हैं) को पहचान सकते हैं लेकिन एसिंक ब्लॉक को उसी लाइन के साथ पहचाना नहीं जा सकता है। दो अलग-अलग वाक्यात्मक रूप स्वीकार्य क्यों हैं, लेकिन तीन नहीं?

RFC पर इस विषय पर कुछ break _without_ का उपयोग करके एक लेबल प्रदान करने के लिए async ब्लॉक के पक्ष में हूं (एसिंक ब्लॉक से बाहरी लूप को तोड़ने का कोई तरीका नहीं है ताकि आप कोई अभिव्यक्ति न खोएं)।

@withboats एक बंद करना सिर्फ एक और प्रकार का कार्य है; एक बार जब आप सीखते हैं कि "एक क्लोजर एक फ़ंक्शन है" तो आप बंद करने के लिए कार्यों के बारे में जो कुछ भी जानते हैं उसे लागू कर सकते हैं, जिसमें " return हमेशा युक्त फ़ंक्शन से वापस आता है" शामिल है।

@ Nemo157 यहां तक ​​​​कि अगर आपने break को async ब्लॉक को लक्षित नहीं किया है, तो आपको एक एसिंक ब्लॉक के अंदर लूप से जल्दी लौटने के लिए एक तंत्र (जैसे 'label: async ) प्रदान करना होगा। .

@joshtriplett

एक बंद करना एक अन्य प्रकार का कार्य है; एक बार जब आप सीखते हैं कि "एक क्लोजर एक फ़ंक्शन है" तो आप बंद करने के लिए कार्यों के बारे में जो कुछ भी जानते हैं उसे लागू कर सकते हैं, जिसमें "वापसी हमेशा युक्त फ़ंक्शन से वापस आती है" शामिल है।

मुझे लगता है कि async ब्लॉक भी एक प्रकार का "फ़ंक्शन" है - बिना किसी तर्क के जिसे एसिंक्रोनस रूप से पूरा करने के लिए चलाया जा सकता है। वे async क्लोजर का एक विशेष मामला है जिसमें कोई तर्क नहीं है और पूर्व-लागू किया गया है।

@cramertj हाँ, मैं मान रहा था कि यदि आवश्यक हो तो किसी भी अंतर्निहित ब्रेक पॉइंट को भी लेबल किया जा सकता है (जैसा कि मेरा मानना ​​​​है कि वे सभी वर्तमान में कर सकते हैं)।

कुछ भी जो नियंत्रण प्रवाह का पालन करना कठिन बनाता है, और विशेष रूप से return अर्थ फिर से परिभाषित करता है, कोड को सुचारू रूप से पढ़ने की क्षमता पर बहुत अधिक दबाव डालता है।

उसी तर्ज पर, सी में मानक मार्गदर्शन "मैक्रो के बीच से लौटने वाले मैक्रोज़ न लिखें"। या, एक कम सामान्य लेकिन अभी भी समस्याग्रस्त मामले के रूप में: यदि आप एक मैक्रो लिखते हैं जो लूप की तरह दिखता है, तो break और continue इसके अंदर से काम करना चाहिए। मैंने देखा है कि लोग लूप-ईश मैक्रोज़ लिखते हैं जो वास्तव में दो लूप एम्बेड करते हैं, इसलिए break अपेक्षा के अनुरूप काम नहीं करता है, और यह बेहद भ्रमित करने वाला है।

मुझे लगता है कि एसिंक ब्लॉक भी एक तरह का "फ़ंक्शन" है

मुझे लगता है कि कार्यान्वयन के आंतरिक ज्ञान को जानने के आधार पर यह एक परिप्रेक्ष्य है।

मैं उन्हें कार्यों के रूप में बिल्कुल नहीं देखता।

मैं उन्हें कार्यों के रूप में बिल्कुल नहीं देखता।

@joshtriplett

मेरा संदेह यह है कि आपने पहली बार बंद होने वाली भाषा में एक ही तर्क दिया होगा-- कि return को बंद करने के भीतर काम नहीं करना चाहिए, लेकिन परिभाषित कार्य के भीतर। और वास्तव में, ऐसी भाषाएं हैं जो इस व्याख्या को लेती हैं, जैसे स्काला।

@cramertj मैं नहीं, नहीं; लैम्ब्डा और/या फ़ंक्शन के भीतर परिभाषित कार्यों के लिए, यह पूरी तरह से स्वाभाविक लगता है कि वे एक फ़ंक्शन हैं। (उन लोगों के लिए मेरा पहला प्रदर्शन पायथन, एफडब्ल्यूआईडब्ल्यू में था, जहां लैम्ब्डा return उपयोग नहीं कर सकते हैं और नेस्टेड कार्यों में return return वाले फ़ंक्शन से रिटर्न।)

मुझे लगता है कि एक बार जब कोई जानता है कि एसिंक ब्लॉक क्या करता है, तो यह सहज रूप से स्पष्ट है कि return को कैसे व्यवहार करना चाहिए। एक बार जब आप जानते हैं कि यह विलंबित निष्पादन का प्रतिनिधित्व करता है, तो यह स्पष्ट है कि return फ़ंक्शन पर लागू नहीं हो सकता है। यह स्पष्ट है कि जब तक ब्लॉक चलता है तब तक फ़ंक्शन पहले ही वापस आ चुका होगा। यह सीखना आईएमओ एक चुनौती का ज्यादा नहीं होना चाहिए। हमें कम से कम इसे आजमा कर देखना चाहिए।

यह RFC यह प्रस्तावित नहीं करता है कि ? -ऑपरेटर और नियंत्रण-प्रवाह निर्माण return , break और continue async ब्लॉकों के अंदर कैसे काम करना चाहिए।

जब तक एक समर्पित आरएफसी नहीं लिखा जाता है, तब तक किसी भी नियंत्रण प्रवाह ऑपरेटरों को अस्वीकार करना या ब्लॉक को स्थगित करना सबसे अच्छा होगा? बाद में चर्चा करने के लिए अन्य वांछित विशेषताओं का उल्लेख किया गया था। इस बीच, हमारे पास एसिंक फ़ंक्शन, क्लोजर और await! :)

मैं यहां @memoryruins से सहमत हूं, मुझे लगता है कि उन विशिष्टताओं पर अधिक विस्तार से चर्चा करने के लिए एक और आरएफसी बनाना उचित होगा।

आप उस फ़ंक्शन के बारे में क्या सोचते हैं जो हमें async fn के अंदर से संदर्भ तक पहुंचने देता है, जिसे शायद core::task::context() कहा जाता है? अगर एसिंक एफएन के बाहर से कॉल किया जाता है तो यह बस घबराएगा। मुझे लगता है कि यह काफी आसान होगा, उदाहरण के लिए निष्पादक को कुछ पैदा करने के लिए उपयोग करना।

@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 में है। एक बार इसे लिबकोर में डालने के बाद मैं इसे सार्वजनिक एपीआई बनाने का प्रस्ताव करता हूं।

मुझे संदेह है कि एक ऐसा फ़ंक्शन होना संभव होगा जिसे गैर- async फ़ंक्शन से बुलाया जा सकता है जो आपको टीएलएस से बाहर ले जाने के बाद कुछ माता-पिता 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/प्रतीक्षा बस उस सीमा का उत्तराधिकारी होगा।

@ Nemo157 आपका मतलब कुछ इस तरह है?

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

@Pzixel एक _संभवतः_ पुरानी चर्चा को जगाने के लिए क्षमा करें, लेकिन मैं अपने विचार जोड़ना चाहूंगा।

हां, मुझे यह पसंद है कि await!() वाक्यविन्यास ? जैसी चीजों के साथ संयोजन करते समय अस्पष्टता को हटा देता है, फिर भी मैं यह भी मानता हूं कि यह वाक्यविन्यास एक परियोजना में एक हजार बार टाइप करने के लिए परेशान है। मैं यह भी मानता हूं कि यह शोर है, और स्वच्छ कोड महत्वपूर्ण है।

इसलिए मैं सोच रहा हूं कि एक प्रत्यय चिह्न (जिसका पहले कुछ बार उल्लेख किया गया है) के खिलाफ वास्तविक तर्क क्या है, जैसे कि something_async()@ 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? ऐसा करता है जहां यह पहली नजर में स्पष्ट नहीं है कि क्या होगा जब तक आप ऐसी स्थिति के बारे में नहीं जानते। और फिर भी इसका कार्यान्वयन ? अनुरूप है।

अब, बस कुछ _minor_ चीजें हैं जिनके बारे में मैं सोच सकता हूं जो इस विचार का विरोध करेंगी:

• हो सकता है कि यह await साथ कुछ के विपरीत _too_ संक्षिप्त और कम दृश्यमान/क्रिया है, जो इसे फ़ंक्शन में निलंबन बिंदुओं को स्पॉट करने के लिए _hard_ बनाता है।
• शायद यह async कीवर्ड के साथ विषम है, जहां एक कीवर्ड है और दूसरा प्रतीक है। हालांकि, await!() एक ही समस्या से ग्रस्त है जो एक मैक्रो बनाम कीवर है।
• एक प्रतीक चुनने से एक और वाक्य रचना तत्व जुड़ जाता है, और सीखने की बात आती है। लेकिन, यह मानते हुए कि यह आमतौर पर इस्तेमाल किया जाने वाला कुछ हो सकता है, मुझे नहीं लगता कि यह कोई समस्या है।

@phaux ने ~ प्रतीक के उपयोग का भी उल्लेख किया। हालाँकि मेरा मानना ​​​​है कि यह चरित्र कुछ कीबोर्ड लेआउट पर टाइप करने के लिए कायरतापूर्ण है इसलिए मैं उस विचार को छोड़ने की सलाह दूंगा।

आपके क्या विचार हैं दोस्तों? क्या आप सहमत हैं कि यह किसी तरह try!() _became_ ? ? क्या आप await या एक प्रतीक पसंद करते हैं, और क्यों? क्या मैं इस पर चर्चा करने के लिए पागल हूँ, या शायद मुझे कुछ याद आ रहा है?

मेरे द्वारा उपयोग की गई किसी भी गलत शब्दावली के लिए क्षमा करें।

सिगिल-आधारित सिंटैक्स के साथ मेरी सबसे बड़ी चिंता यह है कि यह आसानी से ग्लिफ़ सूप में बदल सकता है, जैसा कि आपने कृपया प्रदर्शित किया। पर्ल (पूर्व -6) से परिचित कोई भी व्यक्ति समझ जाएगा कि मैं इसके साथ कहां जा रहा हूं। लाइन शोर से बचना आगे बढ़ने का सबसे अच्छा तरीका है।

जैसा कि कहा गया है, शायद जाने का सबसे अच्छा तरीका वास्तव में वास्तव में के साथ की तरह है try! ? यही है, एक स्पष्ट async!(foo) मैक्रो के साथ शुरू करें, और यदि आवश्यकता हो, तो कुछ सतर्क जोड़ें जो इसके लिए चीनी होगी। निश्चित रूप से, यह समस्या को बाद में स्थगित कर रहा है, लेकिन async!(foo) अपेक्षाकृत विवादास्पद होने के लाभ के साथ, async/प्रतीक्षा के पहले पुनरावृत्ति के लिए पर्याप्त है। (और try! / ? की मिसाल रखने के लिए एक सतर्क होने की आवश्यकता होनी चाहिए)

@withboats मैंने इस पूरे सूत्र को नहीं पढ़ा है, लेकिन क्या कोई कार्यान्वयन में मदद कर रहा है? आपकी विकास शाखा कहाँ है?

और, शेष अनसुलझे विचारों के संबंध में, क्या किसी ने रस्ट समुदाय के बाहर के विशेषज्ञों से मदद मांगी है? जो डफी संगामिति के बारे में बहुत कुछ जानता है और उसकी परवाह करता है और काल्पनिक विवरणों को काफी अच्छी तरह से समझता है , और उसे RustConf में एक

@BatmanAoD एक प्रारंभिक कार्यान्वयन https://github.com/rust-lang/rust/pull/51580 में किया गया था

मूल RFC थ्रेड में PLT स्पेस के कई विशेषज्ञों की टिप्पणियाँ थीं, यहाँ तक कि रस्ट के बाहर भी :)

मैं फ्यूचर्स की प्रतीक्षा के लिए '$' प्रतीक का सुझाव देना चाहूंगा, क्योंकि समय पैसा है, और मैं इसके संकलक को याद दिलाना चाहता हूं।

सिर्फ मजाक करना। मुझे नहीं लगता कि प्रतीक्षा के लिए प्रतीक होना एक अच्छा विचार है। रस्ट का मतलब स्पष्ट होना है, और लोगों को एक शक्तिशाली भाषा में निम्न स्तर का कोड लिखने में सक्षम बनाना है जो आपको अपने आप को पैर में गोली मारने नहीं देता है। एक प्रतीक await! मैक्रो की तुलना में बहुत अधिक अस्पष्ट है, और लोगों को कोड को पढ़ने में मुश्किल लिखकर एक अलग तरीके से पैर में खुद को शूट करने की अनुमति देता है। मैं पहले ही तर्क दूंगा कि ? एक कदम बहुत दूर है।

मैं इस बात से भी असहमत हूं कि async फॉर्म में इस्तेमाल होने वाला कीवर्ड है async fn । इसका तात्पर्य async के प्रति किसी प्रकार का "पूर्वाग्रह" है। एसिंक्स एक कीवर्ड के लायक क्यों है? अतुल्यकालिक कोड हमारे लिए सिर्फ एक और अमूर्त है जो हमेशा आवश्यक नहीं होता है। मुझे लगता है कि एक एसिंक विशेषता बेस रस्ट बोली के "विस्तार" की तरह काम करती है जो हमें अधिक शक्तिशाली कोड लिखने की अनुमति देती है।

मैं कोई भाषा वास्तुकार नहीं हूं, लेकिन मुझे जावास्क्रिप्ट में वादे के साथ एसिंक कोड लिखने का थोड़ा सा अनुभव है, और मुझे लगता है कि जिस तरह से इसे किया गया है, एसिंक कोड को लिखने में खुशी होती है।

@steveklabnik आह, ठीक है, धन्यवाद। क्या हम (/ चाहिए मुझे) समस्या के विवरण को अपडेट कर सकते हैं? शायद बुलेट आइटम "प्रारंभिक कार्यान्वयन" को " move समर्थन के बिना कार्यान्वयन" और "पूर्ण कार्यान्वयन" में विभाजित किया जाना चाहिए?

क्या अगले कार्यान्वयन पुनरावृत्ति पर कुछ सार्वजनिक कांटा/शाखा में काम किया जा रहा है? या क्या वह तब तक आगे नहीं बढ़ सकता जब तक RFC 2418 स्वीकार नहीं कर लिया जाता?

आरएफसी की बजाय एसिंक/प्रतीक्षा वाक्यविन्यास मुद्दे पर चर्चा क्यों की जा रही है?

@ c-edw मुझे लगता है कि async कीवर्ड के बारे में प्रश्न का उत्तर आपका कार्य कौन सा रंग है?

@parasyte मुझे यह सुझाव दिया गया है कि वह पोस्ट वास्तव में स्वचालित रूप से प्रबंधित हरे-थ्रेड शैली

मैं इस स्थिति से असहमत हूं, क्योंकि हरे रंग के धागे को (प्रबंधित) रनटाइम के बिना पारदर्शी रूप से लागू नहीं किया जा सकता है, और जंग की आवश्यकता के बिना एसिंक्रोनस कोड का समर्थन करने का एक अच्छा कारण है।

लेकिन ऐसा लगता है कि आपकी पोस्ट को पढ़ना यह है कि async / await शब्दार्थ ठीक हैं, लेकिन कीवर्ड के बारे में निष्कर्ष निकाला जाना है? क्या आप उस पर विस्तार करना चाहेंगे?

मैं वहां भी आपकी बात से सहमत हूं। मैं टिप्पणी कर रहा था कि async कीवर्ड आवश्यक है, और लेख इसके पीछे तर्क बताता है। लेखक द्वारा निकाले गए निष्कर्ष एक अलग मामला है।

@parasyte आह, ठीक है। खुशी है कि मैंने पूछा - लेखक के लाल/नीले द्विभाजन के प्रति घृणा के कारण, मुझे लगा कि आप इसके विपरीत कह रहे हैं!

मैं और स्पष्ट करना चाहता हूं, क्योंकि मुझे लगता है कि मैंने इसे पूरी तरह से न्याय नहीं किया।

द्विभाजन अपरिहार्य है । कुछ प्रोजेक्ट्स ने प्रत्येक फंक्शन कॉल को एसिंक्स बनाकर इसे मिटाने की कोशिश की है, जिससे यह सुनिश्चित होता है कि सिंक फंक्शन कॉल्स मौजूद नहीं हैं। मिडोरी एक स्पष्ट उदाहरण है। और अन्य परियोजनाओं ने सिंक कार्यों के मुखौटे के पीछे एसिंक कार्यों को छिपाकर द्विभाजन को मिटाने की कोशिश की है। गेवेंट इस तरह का एक उदाहरण है।

दोनों की एक ही समस्या है; उन्हें अभी भी एक अतुल्यकालिक कार्य को पूरा करने और एक कार्य को अतुल्यकालिक रूप से शुरू करने के लिए प्रतीक्षा करने के बीच अंतर करने के लिए द्विभाजन की आवश्यकता है!

• मिडोरी ने न केवल await कीवर्ड पेश किया, बल्कि फ़ंक्शन कॉल साइट पर एक async कीवर्ड भी पेश किया ।
• gevent सामान्य दिखने वाले फ़ंक्शन कॉल्स के निहित-प्रतीक्षा के अलावा gevent.spawn प्रदान करता है।

यही कारण था कि मैंने कलर-ए-फ़ंक्शन आलेख लाया, क्योंकि यह प्रश्न का उत्तर देता है, "एसिंक एक कीवर्ड के लायक क्यों है?"

ठीक है, यहां तक ​​​​कि थ्रेड-आधारित सिंक्रोनस कोड "एक कार्य को पूरा करने की प्रतीक्षा कर रहा है" (जुड़ें) और "एक कार्य शुरू करना" (स्पॉन) को अलग कर सकता है। आप एक ऐसी भाषा की कल्पना कर सकते हैं जहां सब कुछ async (कार्यान्वयन के लिहाज से) है, लेकिन वहां पर कोई टिप्पणी है await (क्योंकि यह डिफ़ॉल्ट व्यवहार है), और मिडोरी के async बजाय एक बंद एक के लिए पारित किया है spawn एपीआई। यह ऑल-एसिंक्स को ठीक उसी सिंटैक्टिक/फ़ंक्शन-कलर फ़ुटिंग पर ऑल-सिंक के रूप में रखता है।

इसलिए जब मैं सहमत हूं कि async एक कीवर्ड के योग्य है, मुझे ऐसा लगता है कि यह अधिक है क्योंकि रस्ट इस स्तर पर कार्यान्वयन के तंत्र की परवाह करता है, और उस कारण से दोनों रंग प्रदान करने की आवश्यकता है।

@rpjohnst हां, मैंने आपके प्रस्ताव पढ़ लिए हैं। यह अवधारणात्मक रूप से रंगों को छुपाने जैसा ही है। जिसकी मैंने रस्ट फोरम पर उसी सूत्र में आलोचना की थी; प्रत्येक फ़ंक्शन कॉल सिंक्रोनस दिखता है जो एक विशेष खतरा होता है जब कोई फ़ंक्शन सिंक्रोनस और एसिंक पाइपलाइन में अवरुद्ध होता है। इस प्रकार की बग अप्रत्याशित है और समस्या निवारण के लिए एक वास्तविक आपदा है।

मैं विशेष रूप से अपने प्रस्ताव के बारे में बात नहीं कर रहा हूं, मैं ऐसी भाषा के बारे में बात कर रहा हूं जहां सब कुछ असीमित है। आप इस तरह से द्वंद्ववाद से बच सकते हैं- मेरा प्रस्ताव ऐसा प्रयास नहीं करता है।

आईआईयूसी ठीक यही मिडोरी ने प्रयास किया। उस समय, कीवर्ड बनाम क्लोजर सिर्फ शब्दार्थ पर बहस कर रहे हैं।

गुरु, जुलाई 12, 2018 अपराह्न 3:01 बजे, रसेल जॉन्सटन सूचनाएं @github.com
लिखा था:

आपने अपने तर्क के रूप में खोजशब्दों की उपस्थिति का उपयोग किया है कि द्विभाजन क्यों?
मिदोरी में अभी भी मौजूद है। यदि आप उन्हें हटा दें, तो द्विभाजन कहाँ है?
सिंटैक्स सभी-सिंक कोड के समान है, लेकिन async की क्षमताओं के साथ
कोड।

क्योंकि जब आप किसी async फ़ंक्शन को उसके परिणाम की प्रतीक्षा किए बिना कॉल करते हैं, तो यह
समकालिक रूप से एक वादा लौटाता है। जिसका बाद में इंतजार किया जा सकता है। मैं

_वाह, किसी को मिडोरी के बारे में कुछ पता है? मैं हमेशा सोच रहा था कि यह एक बंद-परियोजना है जिसमें कोई जीवित प्राणी काम नहीं कर रहा है। यह दिलचस्प होगा यदि आप लोगों में से किसी ने इसके बारे में अधिक विवरण में लिखा हो।_

/विषय से परे

@Pzixel कोई जीवित प्राणी अभी भी इस पर काम नहीं कर रहा है, क्योंकि परियोजना बंद हो गई थी। लेकिन जो डफी के ब्लॉग में बहुत सारे दिलचस्प विवरण हैं। ऊपर मेरे लिंक देखें।

हम यहां पटरी से उतर गए हैं, और मुझे लगता है कि मैं खुद को दोहरा रहा हूं, लेकिन यह "कीवर्ड की उपस्थिति" का हिस्सा है - await कीवर्ड। यदि आप कीवर्ड को spawn और join जैसे API से बदल देते हैं, तो आप पूरी तरह से async (मिडोरी की तरह) हो सकते हैं लेकिन बिना किसी द्विभाजन के (मिडोरी के विपरीत)।

या दूसरे शब्दों में, जैसा कि मैंने पहले कहा, यह मौलिक नहीं है- हमारे पास केवल इसलिए है क्योंकि हम चुनाव चाहते हैं ।

@CyrusNajmabadi आपको फिर से पिंग करने के लिए खेद है, लेकिन यहां निर्णय लेने के बारे में कुछ अतिरिक्त जानकारी दी गई है।

यदि आप दोबारा उल्लेख नहीं करना चाहते हैं तो कृपया मुझे बताएं। मैंने केवल यह सोचा था कि आपकी रुचि हो सकती है।

#wg-net डिस्कॉर्ड चैनल से :

@cramertj
विचार के लिए भोजन: मैं अक्सर async { ... } ब्लॉक के अंत में Ok::<(), MyErrorType>(()) लिख रहा हूं। शायद त्रुटि प्रकार को आसान बनाने के लिए हम कुछ ऐसा कर सकते हैं?

@ नावों के बिना
[...] संभवतः हम चाहते हैं कि यह [ 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 विशेषता के लिए fn- जैसे सिंटैक्स की अनुमति देने के विचार को उछाला था, जैसे Future -> io::Result<()> । इससे मैन्युअल-प्रकार-प्रदान करने का विकल्प थोड़ा बेहतर दिखाई देगा, हालांकि यह अभी भी बहुत सारे वर्ण हैं:

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 = ()> {
    ...
}

संपादित 2: सटीक होने के लिए उपरोक्त आज की विशेषता परिभाषाओं के साथ काम करेगा। यह सिर्फ इतना है कि एक TryFuture प्रकार आज उतना उपयोगी वर्तमान में Future लागू नहीं करता है

@MajorBreakfast क्यों -> impl Future<Output = io::Result<()>> बजाय -> io::Result<()> ? हम पहले से ही async fn foo() -> io::Result<()> लिए रिटर्न-टाइप-डिसुगरिंग करते हैं, इसलिए आईएमओ यदि हम -> -आधारित सिंटैक्स का उपयोग करते हैं तो यह स्पष्ट लगता है कि हम यहां वही चीनी चाहते हैं।

@cramertj हाँ यह सुसंगत होना चाहिए। थोड़े से ऊपर की मेरी पोस्ट मानती है कि मैं आप सभी को समझा सकता हूं कि बाहरी रिटर्न प्रकार का दृष्टिकोण बेहतर है

यदि हम async -> R { .. } साथ जाते हैं तो संभवतः हमें try -> R { .. } साथ-साथ टाइप एसक्रिप्शन के लिए सामान्य रूप से expr -> TheType का उपयोग करना चाहिए। दूसरे शब्दों में, हम जिस टाइप एसक्रिप्शन सिंटैक्स का उपयोग करते हैं उसे समान रूप से हर जगह लागू किया जाना चाहिए।

@ सेंट्रल मैं सहमत हूं। यह हर जगह प्रयोग करने योग्य होना चाहिए। मुझे अब यकीन नहीं है कि -> वास्तव में सही विकल्प है या नहीं। मैं -> को कॉल करने योग्य होने के साथ संबद्ध करता हूं। और async ब्लॉक नहीं हैं।

@MajorBreakfast मैं मूल रूप से सहमत हूँ; मुझे लगता है कि हमें टाइप एसक्रिप्शन के लिए : उपयोग करना चाहिए, इसलिए async : Type { .. } , try : Type { .. } , और expr : Type । हमने डिस्कॉर्ड पर संभावित अस्पष्टताओं पर चर्चा की है और मुझे लगता है कि हमें : साथ आगे का रास्ता मिल गया है जो समझ में आता है ...

एक और सवाल Either एनम के बारे में है। हमारे पास पहले से ही Either में futures टोकरा है। यह भ्रमित करने वाला भी है क्योंकि यह either क्रेट से बिल्कुल Either जैसा दिखता है जब यह नहीं होता है।

क्योंकि Futures लगता है कि एसटीडी में विलय हो गया है (कम से कम इसके बहुत बुनियादी हिस्से) क्या हम वहां 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 इसके अलावा, मैं (व्यक्तिगत रूप से) आशा करता हूं कि Either को इस RFC के साथ पेश नहीं किया जाएगा, क्योंकि यह https://github.com/rust-lang/rfcs/issues का प्रतिबंधित संस्करण पेश करेगा। Future s के साथ), इस प्रकार एपीआई क्रॉफ्ट को जोड़ने की संभावना है यदि एक सामान्य समाधान कभी विलय हो जाता है - और जैसा कि @ निमो157 ने उल्लेख किया है कि यह एक आपात स्थिति नहीं लगती है अभी Either :)

@Ekleog निश्चित रूप से, मुझे इस विचार से either और मैं वास्तव में उनसे छुटकारा पाना चाहता हूं। तब मुझे अपना भ्रम याद आया जब मैंने ~ आधा घंटा बिताया जब तक मुझे एहसास नहीं हुआ कि यह संकलित नहीं है क्योंकि मेरे पास निर्भरता में either टोकरा था (भविष्य की त्रुटियों को समझना काफी कठिन है इसलिए इसमें काफी समय लगा)। इसलिए मैंने टिप्पणी लिखी है, बस यह सुनिश्चित करने के लिए कि इस समस्या का किसी तरह समाधान किया गया है।

बेशक, यह केवल async/await से संबंधित नहीं है, यह अधिक सामान्य बात है, इसलिए यह अपने स्वयं के RFC के योग्य है। मैं केवल इस बात पर जोर देना चाहता था कि या तो futures को either बारे में पता होना चाहिए या इसके विपरीत ( IntoFuture सही तरीके से लागू करने के लिए)।

@Pzixel फ्यूचर्स क्रेट द्वारा निर्यात किया गया Either either क्रेट से एक पुनः निर्यात है। अनाथ नियमों के कारण futures टोकरा 0.3 Future लिए Either लागू नहीं कर सकता है। इस बात की अत्यधिक संभावना है कि हम निरंतरता के लिए Either Stream और Sink लिए Either इम्प्लांट्स को भी हटा देंगे और इसके बजाय एक विकल्प प्रदान करेंगे ( यहां चर्चा की गई either टोकरा तब Future , Stream और Sink को एक फीचर फ्लैग के तहत लागू कर सकता है।

उस ने कहा, जैसा कि @ Nemo157 पहले ही उल्लेख किया गया है, वायदा के साथ काम करते समय, Either बजाय केवल async फ़ंक्शंस का उपयोग करना बेहतर होता है।

async : Type { .. } सामग्री अब https://github.com/rust-lang/rfcs/pull/2522 में प्रस्तावित है

क्या Send स्वचालित रूप से कार्यान्वित करने वाले async/प्रतीक्षा फ़ंक्शन पहले ही लागू हो चुके हैं?

ऐसा लगता है कि निम्न async फ़ंक्शन नहीं है (अभी तक?) 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/प्रतीक्षा कार्य करता है। Rc संस्करण को असंबद्ध करने से उस फ़ंक्शन को गैर- Send रूप में सही ढंग से पता चलता है। मैं आपके विशिष्ट उदाहरण को थोड़ा सा देख सकता हूं (इस मशीन पर कोई जंग संकलक नहीं: थोड़ा_फ्राइंग_फेस :) यह कोशिश करने और काम करने के लिए कि यह क्यों काम नहीं कर रहा है।

@Ekleog std::mpsc::Receiver Sync , और आपके द्वारा लिखा गया async fn इसका संदर्भ रखता है। !Sync आइटम के संदर्भ हैं !Send ।

@cramertj हम्म ... लेकिन, क्या मेरे पास स्वामित्व वाला mpsc::Receiver , जो Send होना चाहिए यदि इसका सामान्य प्रकार Send ? (साथ ही, यह std::mpsc::Receiver बल्कि एक futures::channel::mpsc::Receiver , जो कि Sync भी है, यदि प्रकार Send , तो mpsc::Receiver ध्यान न देने के लिए खेद है

@ निमो157 धन्यवाद! मैंने इस मुद्दे पर बहुत अधिक शोर से बचने के लिए https://github.com/rust-lang/rust/issues/53259 खोला है :)

की क्या और कितनी सवाल async ब्लॉक की अनुमति देने के ? और अन्य नियंत्रण प्रवाह के साथ कुछ बातचीत वारंट सकता है try (ब्लॉक जैसे try async { .. } अनुमति देने के लिए ? समान भ्रम के बिना return ?)

इसका मतलब है कि async ब्लॉक के प्रकार को निर्दिष्ट करने के लिए तंत्र को try ब्लॉक के प्रकार को निर्दिष्ट करने के लिए तंत्र के साथ बातचीत करने की आवश्यकता हो सकती है। मैंने एसक्रिप्शन सिंटैक्स आरएफसी पर एक टिप्पणी छोड़ी: https://github.com/rust-lang/rfcs/pull/2522#issuecomment -412577175

बस वही मारा जो पहले मैंने सोचा था कि एक futures-rs मुद्दा था, लेकिन यह पता चला कि यह वास्तव में एक async/प्रतीक्षा मुद्दा हो सकता है, इसलिए यहां यह है: https://github.com/rust-lang-nursery/ Futures-rs/issues/1199#issuecomment -413089012

एक नया मुद्दा: https://github.com/rust-lang/rust/issues/53447

जैसा कि कुछ दिनों पहले कलह पर चर्चा की गई थी, await को अभी तक एक कीवर्ड के रूप में आरक्षित नहीं किया गया है। 2018 रिलीज से पहले इस आरक्षण को (और 2018 संस्करण कीवर्ड लिंट में जोड़ा गया) प्राप्त करना बहुत महत्वपूर्ण है। यह थोड़ा जटिल आरक्षण है क्योंकि हम अभी के लिए मैक्रो सिंटैक्स का उपयोग जारी रखना चाहते हैं।

क्या फ्यूचर/टास्क एपीआई के पास स्थानीय फ्यूचर्स को बढ़ाने का एक तरीका होगा?
मैं देखता हूं कि SpawnLocalObjError , लेकिन ऐसा लगता है कि यह अप्रयुक्त है।

@panicbit कार्य समूह में हम वर्तमान में चर्चा कर रहे हैं कि क्या संदर्भ में स्पॉनिंग कार्यक्षमता को शामिल करना समझ में आता है। https://github.com/rust-lang-nursery/wg-net/issues/56

( SpawnLocalObjError पूरी तरह से अप्रयुक्त नहीं है: LocalPool फ्यूचर्स क्रेट इसका उपयोग करता है। आप सही हैं, हालांकि, libcore में कुछ भी इसका उपयोग नहीं करता है)

@withboats मैंने देखा कि समस्या विवरण के कुछ लिंक पुराने हैं। विशेष रूप से, https://github.com/rust-lang/rfcs/pull/2418 बंद है और https://github.com/rust-lang-nursery/futures-rs/issues/1199 को https:/ पर ले जाया गया है

नायब। इस ट्रैकिंग समस्या का नाम async/प्रतीक्षा है लेकिन इसे कार्य API को भी असाइन किया गया है! कार्य API में वर्तमान में एक स्थिरीकरण RFC लंबित है: https://github.com/rust-lang/rfcs/pull/2592

वैकल्पिक एसिंक्स कार्यान्वयन के लिए कीवर्ड को पुन: प्रयोज्य बनाने का कोई मौका? वर्तमान में यह एक भविष्य बनाता है, लेकिन यह पुश आधारित एसिंक्स को अधिक उपयोगी बनाने के लिए एक चूक का अवसर है।

@aep oneshot::channel का उपयोग करके पुश-आधारित सिस्टम से पुल-आधारित फ्यूचर सिस्टम में आसानी से परिवर्तित करना संभव है।

एक उदाहरण के रूप में, जावास्क्रिप्ट वादे पुश-आधारित हैं, इसलिए stdweb जावास्क्रिप्ट वादों को रस्ट फ्यूचर्स में बदलने के लिए oneshot::channel का उपयोग करता है । यह कुछ अन्य पुश-आधारित कॉलबैक एपीआई के लिए oneshot::channel का भी उपयोग करता है, जैसे setTimeout ।

रस्ट के मेमोरी मॉडल के कारण, पुश आधारित फ्यूचर्स में पुल की तुलना में अतिरिक्त प्रदर्शन लागत होती है । इसलिए संपूर्ण फ्यूचर सिस्टम को पुश-आधारित होने के बजाय केवल जरूरत पड़ने पर (जैसे oneshot::channel का उपयोग करके) उस प्रदर्शन लागत का भुगतान करना बेहतर है।

ऐसा कहने के बाद, मैं कोर या लैंग टीमों का हिस्सा नहीं हूं, इसलिए मैं जो कुछ भी कहता हूं उसका कोई अधिकार नहीं है। यह सिर्फ मेरी निजी राय है।

यह वास्तव में संसाधन बाधित कोड में दूसरी तरफ है। पुल मॉडल पर जुर्माना लगाया जाता है क्योंकि प्रतीक्षा कार्यों के ढेर के माध्यम से अगले तैयार मूल्य को खिलाने के बजाय आपको उस चीज़ के अंदर संसाधन की आवश्यकता होती है जिसे खींचा जा रहा है। फ्यूचर्स.आरएस डिज़ाइन हार्डवेयर के करीब किसी भी चीज़ के लिए बहुत महंगा है, जैसे नेटवर्क स्विच (मेरा उपयोग केस) या गेम रेंडरर्स।

हालांकि, इस मामले में हमें यहां केवल एसिंक्स को जेनरेटर की तरह कुछ उत्सर्जित करना होगा। जैसा कि मैंने पहले कहा था, मुझे लगता है कि एसिंक और जेनरेटर वास्तव में वही चीज हैं यदि आप एक पुस्तकालय में दो कीवर्ड बाध्य करने के बजाय इसे पर्याप्त रूप से सार करते हैं।

हालांकि, इस मामले में हमें यहां केवल एसिंक्स को जेनरेटर की तरह कुछ उत्सर्जित करना होगा।

इस बिंदु पर async वस्तुतः एक जनरेटर शाब्दिक के आसपास एक न्यूनतम आवरण है। मुझे यह देखने में कठिनाई हो रही है कि जेनरेटर पुश आधारित एसिंक्स आईओ के साथ कैसे मदद करते हैं, क्या आपको उनके लिए सीपीएस ट्रांसफॉर्म की आवश्यकता नहीं है?

क्या आप इस बारे में अधिक विशिष्ट हो सकते हैं कि "आपको खींची जा रही चीज़ के अंदर संसाधनों की आवश्यकता है?" मुझे यकीन नहीं है कि आपको इसकी आवश्यकता क्यों होगी, या "प्रतीक्षा कार्यों के ढेर के माध्यम से अगले तैयार मूल्य को कैसे खिलाना" poll() से अलग है।

मैं इस धारणा के तहत था कि पुश-आधारित वायदा अधिक महंगा था (और इस प्रकार विवश वातावरण में उपयोग करना कठिन था)। भविष्य से जुड़े होने के लिए मनमाने ढंग से कॉलबैक की अनुमति देने के लिए कुछ प्रकार के संकेत की आवश्यकता होती है, आम तौर पर ढेर आवंटन, इसलिए मूल भविष्य के साथ एक बार आवंटित करने के बजाय आप प्रत्येक संयोजक पर आवंटित करते हैं। और थ्रेड सुरक्षा मुद्दों के कारण रद्दीकरण भी अधिक जटिल हो जाता है, इसलिए आप या तो इसका समर्थन नहीं करते हैं या रेसिंग से बचने के लिए परमाणु ऑप्स का उपयोग करने के लिए आपको सभी कॉलबैक पूर्ण करने की आवश्यकता होती है। जहां तक ​​​​मैं कह सकता हूं, यह सब ढांचे को अनुकूलित करने के लिए बहुत कठिन हो जाता है।

क्या आपको उनके लिए CPS रूपांतरण की आवश्यकता नहीं है?

हाँ, वर्तमान जनरेटर सिंटैक्स इसके लिए काम नहीं करता है क्योंकि इसमें निरंतरता के लिए तर्क नहीं हैं, यही कारण है कि मैं उम्मीद कर रहा था कि एसिंक इसे करने के तरीकों में लाएगा।

आपको खींची जा रही चीज़ के अंदर संसाधनों की आवश्यकता है?

यह कहने का मेरा भयानक तरीका है कि ऑर्डर को उलटने से async दो बार काम करता है। यानी एक बार हार्डवेयर से फ्यूचर तक और फिर चैनलों का उपयोग करके वापस। आपको सामान का एक पूरा गुच्छा ले जाने की आवश्यकता है जिसका निकट-हार्डवेयर कोड में शून्य लाभ है।

एक सामान्य उदाहरण यह होगा कि जब आप जानते हैं कि सॉकेट का फ़ाइल डिस्क्रिप्टर तैयार है, तो आप भविष्य के स्टैक का आह्वान नहीं कर सकते हैं, बल्कि वास्तविक दुनिया की घटनाओं को फ्यूचर्स में मैप करने के लिए सभी निष्पादन तर्क को लागू करना होगा, जिसमें बाहरी लागत जैसे लॉकिंग, कोड आकार और सबसे महत्वपूर्ण कोड जटिलता।

भविष्य से जुड़े होने के लिए मनमाने ढंग से कॉलबैक की अनुमति देने के लिए किसी प्रकार के संकेत की आवश्यकता होती है

हां, मैं समझता हूं कि कुछ वातावरणों में कॉलबैक महंगे हैं (मेरे में नहीं, जहां निष्पादन की गति अप्रासंगिक है, लेकिन मेरे पास कुल 1 एमबी मेमोरी है, इसलिए फ्यूचर्स.आरएस फ्लैश पर भी फिट नहीं होता है), हालांकि, जब आपके पास गतिशील प्रेषण की आवश्यकता नहीं होती है निरंतरता जैसा कुछ (जो वर्तमान जनरेटर अवधारणा आधा-लागू करता है)।

और थ्रेड सुरक्षा के कारण रद्दीकरण भी अधिक जटिल हो जाता है

मुझे लगता है कि हम यहां चीजों को भ्रमित कर रहे हैं। मैं कॉलबैक की वकालत नहीं कर रहा हूं। निरंतरता स्थिर ढेर ठीक हो सकती है। उदाहरण के लिए हमने मिट्टी की भाषा में जो लागू किया वह सिर्फ एक जनरेटर पैटर्न है जिसे आप पुश या पुल के लिए उपयोग कर सकते हैं। अर्थात:

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

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

मुझे लगता है कि मैं मैक्रो के साथ ऐसा करना जारी रख सकता हूं, लेकिन मुझे लगता है कि यह एक विशेष अवधारणा पर एक भाषा कीवर्ड बर्बाद करने का एक चूक अवसर है।

मेरे में नहीं, जहां निष्पादन की गति अप्रासंगिक है, लेकिन मेरे पास कुल 1MB मेमोरी है, इसलिए Futures.rs फ्लैश पर भी फिट नहीं होता है

मुझे पूरा यकीन है कि वर्तमान वायदा स्मृति-विवश वातावरण में चलने का इरादा है। वास्तव में इतनी जगह क्या ले रहा है?

संपादित करें: मेरी मैकबुक पर संकलित होने पर यह प्रोग्राम 295KB डिस्क स्थान लेता है (मूल हैलो वर्ल्ड 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 मेमोरी है, इसलिए Futures.rs फ्लैश पर भी फिट नहीं होता है

मुझे पूरा यकीन है कि वर्तमान वायदा स्मृति-विवश वातावरण में चलने का इरादा है। वास्तव में इतनी जगह क्या ले रहा है?

इसके अलावा स्मृति से आपका क्या मतलब है? मैंने 128 केबी फ्लैश/16 केबी रैम वाले उपकरणों पर वर्तमान एसिंक/प्रतीक्षा आधारित कोड चलाया है। वर्तमान में एसिंक/प्रतीक्षा के साथ स्मृति उपयोग के मुद्दे निश्चित रूप से हैं, लेकिन वे ज्यादातर कार्यान्वयन के मुद्दे हैं और कुछ अतिरिक्त अनुकूलन जोड़कर सुधार किया जा सकता है (उदाहरण के लिए https://github.com/rust-lang/rust/issues/52924)।

एक सामान्य उदाहरण यह होगा कि जब आप जानते हैं कि सॉकेट का फ़ाइल डिस्क्रिप्टर तैयार है, तो आप भविष्य के स्टैक का आह्वान नहीं कर सकते हैं, बल्कि वास्तविक दुनिया की घटनाओं को फ्यूचर्स में मैप करने के लिए सभी निष्पादन तर्क को लागू करना होगा, जिसमें बाहरी लागत जैसे लॉकिंग, कोड आकार और सबसे महत्वपूर्ण कोड जटिलता।

क्यों? यह अभी भी ऐसा कुछ भी नहीं लगता है जो वायदा आपको मजबूर करता है। आप उतनी ही आसानी से poll कॉल कर सकते हैं, जैसा कि आप पुश-आधारित तंत्र को कहते हैं।

इसके अलावा स्मृति से आपका क्या मतलब है?

मुझे नहीं लगता कि यह प्रासंगिक है। इस पूरी चर्चा ने एक ऐसे बिंदु को अमान्य करने के बारे में विस्तार से बताया है जिसे मैं बनाने का इरादा भी नहीं रखता था। मैं यह कहने के अलावा वायदा की आलोचना करने के लिए यहां नहीं हूं कि इसकी डिजाइन को मूल भाषा में बांधना एक गलती है।

मेरी बात यह है कि अगर इसे ठीक से किया जाए तो async कीवर्ड को भविष्य का प्रमाण बनाया जा सकता है। निरंतरता वही है जो मैं चाहता हूं, लेकिन हो सकता है कि अन्य लोग और भी बेहतर विचार लेकर आएं।

आप पोल को उतनी ही आसानी से कॉल कर सकते हैं जितना कि आप पुश-आधारित तंत्र को कहते हैं।

हां, यह समझ में आता है कि भविष्य: मतदान में कॉल आर्ग थे। यह उनके पास नहीं हो सकता क्योंकि मतदान को सारगर्भित होना चाहिए। इसके बजाय मैं async कीवर्ड से निरंतरता का उत्सर्जन करने का प्रस्ताव कर रहा हूं, और भविष्य को शून्य तर्कों के साथ किसी भी निरंतरता के लिए लागू कर रहा हूं।

यह एक सरल, कम प्रयास वाला परिवर्तन है जो वायदा में कोई लागत नहीं जोड़ता है, लेकिन उन खोजशब्दों की पुन: प्रयोज्यता की अनुमति देता है जो वर्तमान में विशेष रूप से एक पुस्तकालय के लिए हैं।

लेकिन निश्चित रूप से एक प्रीप्रोसेसर के साथ भी निरंतरता को लागू किया जा सकता है, जो कि हम करने जा रहे हैं। दुर्भाग्य से desugar केवल एक बंद हो सकता है, जो उचित निरंतरता से अधिक महंगा है।

@aep हम कीवर्ड ( async और await ) का पुन: उपयोग कैसे संभव करेंगे?

@Centril मेरा भोला त्वरित सुधार एक जनरेटर को एक भविष्य के लिए नहीं एक async को कम करना होगा। इससे जनरेटर को वायदा के लिए एक विशेष बैकएंड होने के बजाय उचित निरंतरता के लिए उपयोगी बनाने का समय मिल जाएगा।

यह एक 10 लाइन पीआर की तरह हो सकता है। लेकिन मेरे पास इस पर मधुमक्खी के छत्ते से लड़ने का धैर्य नहीं है, इसलिए मैं एक अलग कीवर्ड को डिसुगर करने के लिए सिर्फ एक प्रीप्रोक बनाऊंगा।

मैं एसिंक्स सामान का पालन नहीं कर रहा हूं इसलिए क्षमा चाहता हूं अगर इस पर पहले/अन्य जगहों पर चर्चा की गई है, लेकिन no_std में async/प्रतीक्षा का समर्थन करने के लिए (कार्यान्वयन) योजना क्या है?

AFAICT वर्तमान कार्यान्वयन एक वेकर को पास करने के लिए TLS का उपयोग करता है लेकिन no_std / core कोई TLS (या थ्रेड) समर्थन नहीं है। मैंने @alexcrichton से सुना है कि टीएलएस से छुटकारा पाना संभव हो सकता है यदि/जब Generator.resume तर्कों के लिए समर्थन प्राप्त करता है।

क्या no_std समर्थन पर async / प्रतीक्षा के स्थिरीकरण को रोकने की योजना लागू की जा रही है? या क्या हमें यकीन है कि no_std समर्थन किसी भी टुकड़े को बदले बिना जोड़ा जा सकता है जो std async / स्थिर पर प्रतीक्षा करने के लिए स्थिर हो जाएगा?

@japaric poll अब संदर्भ को स्पष्ट रूप से लेता है। AFAIK, TLS की अब आवश्यकता नहीं होनी चाहिए।

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

संपादित करें: एसिंक/प्रतीक्षा के लिए प्रासंगिक नहीं, केवल वायदा के लिए।

[...] क्या हम सुनिश्चित हैं कि no_std समर्थन को किसी भी टुकड़े को बदले बिना जोड़ा जा सकता है जो std async/स्थिर पर प्रतीक्षा करने के लिए स्थिर हो जाएगा?

मुझे ऐसा विश्वास है। प्रासंगिक टुकड़े std::future , ये सभी एक अतिरिक्त gen_future अस्थिर सुविधा के पीछे छिपे हुए हैं जो कभी भी स्थिर नहीं होंगे। async ट्रांसफॉर्म set_task_waker का उपयोग वेकर को टीएलएस में स्टोर करने के लिए करता है फिर await! तक पहुंच प्राप्त करने के लिए poll_with_tls_waker का उपयोग करता है। यदि जनरेटर को फिर से शुरू तर्क समर्थन मिलता है तो इसके बजाय async परिवर्तन वेकर को फिर से शुरू तर्क के रूप में पारित कर सकता है और await! इसे तर्क से बाहर पढ़ सकता है।

संपादित करें: जेनरेटर तर्कों के बिना भी मेरा मानना ​​​​है कि यह एसिंक ट्रांसफॉर्म में कुछ और जटिल कोड के साथ भी किया जा सकता है। मैं व्यक्तिगत रूप से अन्य उपयोग-मामलों के लिए जोड़े गए जनरेटर तर्कों को देखना चाहूंगा, लेकिन मुझे पूरा यकीन है कि उनके साथ/बिना टीएलएस आवश्यकता को हटाना संभव होगा।

@japaric वही नाव। यहां तक ​​​​कि अगर किसी ने फ्यूचर्स को एम्बेडेड पर काम किया है, तो यह बहुत ही जोखिम भरा है क्योंकि यह सभी टियर 3 है।

मुझे एक बदसूरत हैक का पता चला है जिसमें async को ठीक करने की तुलना में बहुत कम काम की आवश्यकता होती है: एक आर्क में बुनाईजेनरेटर के ढेर के माध्यम से।

1. "पोल" तर्क देखें https://github.com/aep/osaka/blob/master/osaka-dns/src/lib.rs#L76 इसका एक आर्क
2. लाइन 87 . पर मतदान में कुछ दर्ज करना
3. उपज लाइन 92 . पर एक निरंतरता बिंदु उत्पन्न करने के लिए
4. लाइन 207 . पर एक उच्च स्तरीय स्टैक बनाने के लिए जनरेटर से जनरेटर को कॉल करें
5. अंत में 215 line लाइन पर रनटाइम में पास करके पूरे स्टैक को निष्पादित करना

आदर्श रूप से वे भविष्य के बजाय "शुद्ध" क्लोजर स्टैक के लिए एसिंक्स को कम कर देंगे ताकि आपको किसी रनटाइम धारणा की आवश्यकता न हो और फिर आप रूट पर तर्क के रूप में अशुद्ध वातावरण में धक्का दे सकें।

मैं इसे लागू करने में आधा था

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

लेकिन अगर मैं अकेला हूं जो इसे चाहता है तो सभी तरह से जाने का कोई मतलब नहीं है।

और मैं इस बारे में सोचना बंद नहीं कर सका कि जनरेटर तर्कों के बिना टीएलएस-कम एसिंक/प्रतीक्षा संभव है, इसलिए मैंने no_std proc-macro आधारित async_block! / await! मैक्रो जोड़ी लागू की केवल स्थानीय चर का उपयोग करना।

यह निश्चित रूप से वर्तमान टीएलएस आधारित समाधान या जनरेटर तर्क आधारित समाधान की तुलना में बहुत अधिक सूक्ष्म सुरक्षा गारंटी की आवश्यकता है (कम से कम जब आप मानते हैं कि अंतर्निहित जनरेटर तर्क ध्वनि हैं), लेकिन मुझे पूरा यकीन है कि यह ध्वनि है (जब तक कोई भी नहीं बड़े स्वच्छता छेद का उपयोग करता है, मुझे कोई रास्ता नहीं मिल रहा है, यह इन-कंपाइलर कार्यान्वयन के लिए कोई समस्या नहीं होगी क्योंकि यह एसिंक ट्रांसफॉर्म और प्रतीक्षा मैक्रो के बीच संवाद करने के लिए अज्ञात जेन्सिम पहचान का उपयोग कर सकता है)।

मुझे अभी एहसास हुआ कि ओपी में await! को std से core ले जाने का कोई उल्लेख नहीं है, शायद #56767 को ट्रैक करने के लिए स्थिरीकरण से पहले हल करने के लिए मुद्दों की सूची में जोड़ा जा सकता है यह।

@ Nemo157 await! स्थिर होने की उम्मीद नहीं है, यह वैसे भी अवरोधक नहीं है।

@Centril मुझे नहीं पता कि आपको किसने बताया कि await! स्थिर होने की उम्मीद नहीं है ...: पलक:

@cramertj उनका मतलब मैक्रो संस्करण था, न कि कीवर्ड संस्करण जो मुझे विश्वास है ...

@ crlf0710 निहित प्रतीक्षा/स्पष्ट एसिंक -ब्लॉक संस्करण के बारे में क्या है?

@ crlf0710 मैंने भी किया :)

@cramertj क्या हम मैक्रो को हटाना नहीं चाहते हैं क्योंकि वर्तमान में कंपाइलर में एक बदसूरत हैक है जो await और await! दोनों के अस्तित्व को संभव बनाता है? यदि हम मैक्रो को स्थिर करते हैं, तो हम इसे कभी भी हटा नहीं पाएंगे।

@stjepang मुझे वास्तव में await! के सिंटैक्स के बारे में किसी भी दिशा में बहुत अधिक परवाह नहीं है, पोस्टफिक्स नोटेशन के लिए सामान्य वरीयता और अस्पष्टता और अप्राप्य/अन-Google-सक्षम प्रतीकों के नापसंद से अलग। जहां तक ​​​​मुझे पता है, वर्तमान सुझाव ( ? के साथ पूर्वता स्पष्ट करने के लिए) हैं:

• await!(x)? (आज हमारे पास क्या है)
• await x? ( await ? से अधिक कड़े बांधता है, फिर भी उपसर्ग संकेतन, चेन विधियों के लिए माता-पिता की आवश्यकता होती है)
• await {x}? (ऊपर जैसा ही है, लेकिन स्पष्ट करने के लिए अस्थायी रूप से {} आवश्यकता है)
• await? x ( await कम कसकर बांधता है, फिर भी उपसर्ग संकेतन, श्रृंखला विधियों के लिए माता-पिता की आवश्यकता होती है)
• x.await? (फ़ील्ड एक्सेस की तरह दिखता है)
• x# / x~ /आदि। (कुछ प्रतीक)
• x.await!()? ( पोस्टफ़िक्स -मैक्रो-स्टाइल, पोस्टफ़िक्स -मैक्रोज़ प्रशंसक नहीं हैं क्योंकि वे टाइप-आधारित प्रेषण की अनुमति देने के लिए . अपेक्षा करते हैं, जो कि पोस्टफ़िक्स मैक्रोज़ के लिए नहीं होगा। )

मुझे लगता है कि शिपिंग के लिए सबसे अच्छा मार्ग 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 जनरेटर के लिए "सिर्फ" वाक्यात्मक चीनी है। यह मेरे दिन जहां जावास्क्रिप्ट async / इंतजार समर्थन हो रही थी की याद दिलाता है और आप कोलाहल और जैसी परियोजनाओं के लिए किया था सुधारनेवाला कि उपयोग जनरेटर और वादे को transpiled async कोड / async के संचालन के लिए फ्यूचर्स, हम कर रहे हैं अनिवार्य रूप से की तरह।

ध्यान रखें कि अंततः हम चाहते हैं कि एसिंक्स और जेनरेटर अलग-अलग विशेषताएं हों, संभावित रूप से एक-दूसरे के साथ भी संगत हों (एक Stream )। await! को मैक्रो के रूप में छोड़ना जो केवल yield जाता है, एक स्थायी समाधान नहीं है।

प्रतीक्षा छोड़कर! एक मैक्रो के रूप में जो केवल उपज को कम करता है वह स्थायी समाधान नहीं है।

यह स्थायी रूप से उपयोगकर्ता-दृश्यमान नहीं हो सकता है कि यह yield कम हो जाता है, लेकिन इसे निश्चित रूप से इस तरह कार्यान्वित किया जा सकता है। यहां तक ​​​​कि जब आपके पास async + जनरेटर = Stream हो तब भी आप उदाहरण के लिए yield Poll::Pending; बनाम yield Poll::Ready(next_value) ।

ध्यान रखें कि अंततः हम चाहते हैं कि एसिंक्स और जेनरेटर अलग-अलग विशेषताएं हों

क्या एसिंक्स और जेनरेटर अलग-अलग विशेषताएं नहीं हैं ? संबंधित, निश्चित रूप से, लेकिन इसे फिर से तुलना करना कि जावास्क्रिप्ट ने इसे कैसे किया, मैंने हमेशा सोचा कि जनरेटर के शीर्ष पर एसिंक बनाया जाएगा; कि केवल एक एसिंक फ़ंक्शन होने का अंतर वापस आ जाएगा और किसी भी नियमित मूल्य के विपरीत Future s प्राप्त करेगा। एक निष्पादक को मूल्यांकन करने और निष्पादित करने के लिए async फ़ंक्शन पर प्रतीक्षा करने की आवश्यकता होगी। इसके अलावा कुछ अतिरिक्त आजीवन सामान मुझे यकीन नहीं है।

वास्तव में, मैंने एक बार इस सटीक चीज़ के बारे में एक पुस्तकालय लिखा था , जो वादा/वायदा लौटाने वाले एसिंक फ़ंक्शंस और जेनरेटर फ़ंक्शंस दोनों का दोबारा मूल्यांकन करता है।

@cramertj इसे इस तरह लागू नहीं किया जा सकता है यदि दोनों अलग-अलग "प्रभाव" हैं। इसके बारे में यहाँ कुछ चर्चा है: https://internals.rust-lang.org/t/pre-rfc-await-generators-directly/7202। हम yield Poll::Ready(next_value) नहीं चाहते हैं, हम yield next_value , और उसी फ़ंक्शन में कहीं और await ।

@rpjohnst

हम पोल :: रेडी (नेक्स्ट_वैल्यू) नहीं देना चाहते हैं, हम नेक्स्ट_वैल्यू प्राप्त करना चाहते हैं, और उसी फ़ंक्शन में कहीं और प्रतीक्षा कर रहे हैं।

हां, निश्चित रूप से यह उपयोगकर्ता की तरह दिखाई देगा, लेकिन desugaring के मामले में आपको yield s को Poll::Ready लपेटना होगा और Poll::Pending को जोड़ना होगा yield उत्पन्न await! । अंतिम उपयोगकर्ताओं के लिए वाक्य-विन्यास के रूप में वे अलग-अलग विशेषताओं के रूप में दिखाई देते हैं, लेकिन वे अभी भी संकलक में एक कार्यान्वयन साझा कर सकते हैं।

@cramertj यह भी एक:

• await? x

@novacrazy हाँ, वे अलग विशेषताएं हैं, लेकिन वे एक साथ composable होना चाहिए।

और वास्तव में जावास्क्रिप्ट में वे composable हैं:

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

"Async जनरेटर और इटरेटर वे हैं जो आपको तब मिलते हैं जब आप एक async फ़ंक्शन और एक इटरेटर को मिलाते हैं, इसलिए यह एक async जनरेटर की तरह है जिसमें आप प्रतीक्षा कर सकते हैं या एक async फ़ंक्शन जिससे आप प्राप्त कर सकते हैं," उन्होंने समझाया। पहले, ईसीएमएस्क्रिप्ट ने आपको एक ऐसा फ़ंक्शन लिखने की अनुमति दी थी जिसमें आप उपज कर सकते थे या प्रतीक्षा कर सकते थे लेकिन दोनों नहीं। "यह उन धाराओं का उपभोग करने के लिए वास्तव में सुविधाजनक है जो वेब प्लेटफ़ॉर्म का अधिक से अधिक हिस्सा बन रहे हैं, विशेष रूप से फ़ेच ऑब्जेक्ट स्ट्रीम को उजागर करने के साथ।"

एसिंक्स इटरेटर ऑब्जर्वेबल पैटर्न के समान है, लेकिन अधिक लचीला है। "एक ऑब्जर्वेबल एक पुश मॉडल है; एक बार जब आप इसकी सदस्यता लेते हैं, तो आप पूरी गति से घटनाओं और सूचनाओं के साथ विस्फोट हो जाते हैं, चाहे आप तैयार हों या नहीं, इसलिए आपको चैटिंग से निपटने के लिए बफरिंग या सैंपलिंग रणनीतियों को लागू करना होगा, ”टेरल्सन ने समझाया। एसिंक इटरेटर एक पुश-पुल मॉडल है - आप एक मूल्य मांगते हैं और यह आपको भेजा जाता है - जो नेटवर्क आईओ प्राइमेटिव जैसी चीजों के लिए बेहतर काम करता है।

@Centril ठीक है, # 56974 खोला गया, क्या यह ओपी के लिए एक अनसुलझे प्रश्न के रूप में जोड़े जाने के लिए पर्याप्त है?

मैं वास्तव में await सिंटैक्स में फिर से प्रवेश नहीं करना चाहता, लेकिन मुझे कम से कम एक बिंदु का जवाब देना होगा:

व्यक्तिगत रूप से मुझे await! मैक्रो पसंद है जैसा कि यह है और जैसा कि यहां बताया गया है: https://blag.nemo157.com/2018/12/09/inside-rusts-async-transform.html

ध्यान दें कि मैंने यह भी कहा है कि मुझे विश्वास नहीं है कि मैक्रो एक पुस्तकालय लागू मैक्रो बना रह सकता है (यह अनदेखा कर रहा है कि यह उपयोगकर्ताओं के लिए मैक्रो के रूप में दिखाई देगा या नहीं), कारणों पर विस्तार करने के लिए:

1. अंतर्निहित कार्यान्वयन को छिपाना, जैसा कि अनसुलझे मुद्दों में से एक कहता है कि आप वर्तमान में || await!() का उपयोग करके जनरेटर बना सकते हैं।
2. एसिंक जेनरेटर का समर्थन करना, जैसा कि yield s द्वारा जोड़े गए await और उपयोगकर्ता द्वारा लिखे गए अन्य yield बीच अंतर करने की आवश्यकता है। यह एक पूर्व वृहद विस्तार चरण के रूप में किया _could_ जा, _if_ उपयोगकर्ताओं कभी नहीं करना चाहता था yield मैक्रो के अंदर है, लेकिन वहाँ बहुत उपयोगी होते हैं yield -इन-मैक्रो तरह निर्माणों yield_from! . इस बाधा के साथ कि मैक्रोज़ में yield s का समर्थन किया जाना चाहिए, इसके लिए await! को कम से कम एक अंतर्निहित मैक्रो होना आवश्यक है (यदि वास्तविक सिंटैक्स नहीं है)।
3. समर्थन async fn पर no_std । मैं इसे लागू करने के दो तरीकों के बारे में जानता हूं, दोनों तरीकों के लिए async fn -created- Future और await ताकि एक पहचानकर्ता साझा किया जा सके जिसमें वेकर संग्रहीत है। एकमात्र तरीका मैं देख सकते हैं कि इन दो स्थानों के बीच एक स्वच्छ रूप से सुरक्षित पहचानकर्ता साझा किया गया है, यदि दोनों को कंपाइलर में लागू किया गया है।

मुझे लगता है कि यहां कुछ भ्रम है-- यह कभी भी इरादा नहीं था कि await! कॉल के चारों ओर एक रैपर के लिए सार्वजनिक रूप रूप से विस्तार योग्य हो yield । await! मैक्रो-जैसे सिंटैक्स के लिए कोई भी भविष्य एक कार्यान्वयन पर निर्भर करेगा जो वर्तमान कंपाइलर-समर्थित compile_error! , assert! , format_args! आदि के विपरीत नहीं है। और संदर्भ के आधार पर अलग-अलग कोड को डिसुगर करने में सक्षम होगा।

यहां समझने के लिए एकमात्र महत्वपूर्ण बात यह है कि प्रस्तावित वाक्यविन्यासों में से किसी के बीच कोई महत्वपूर्ण अर्थ अंतर नहीं है- वे केवल सतह वाक्यविन्यास हैं।

मैं await सिंटैक्स को हल करने के लिए एक विकल्प लिखूंगा।

सबसे पहले मुझे यह विचार पसंद आया जिसने await को पोस्टफिक्स ऑपरेटर के रूप में रखा। लेकिन expression.await एक क्षेत्र की तरह बहुत अधिक है, जैसा कि पहले ही बताया जा चुका है।

तो मेरा प्रस्ताव expression awaited । यहां नुकसान यह है कि awaited अभी तक एक कीवर्ड के रूप में संरक्षित नहीं है, लेकिन यह अंग्रेजी में अधिक स्वाभाविक है और फिर भी ऐसी कोई अभिव्यक्ति नहीं है (मेरा मतलब है, व्याकरण के रूप जैसे expression [token] ) जंग में मान्य है अभी, इसलिए इसे उचित ठहराया जा सकता है।

तो फिर हम लिख सकते हैं expression? awaited एक का इंतजार कर के लिए Result<Future,_> , और expression awaited? एक का इंतजार कर के लिए Future<Item=Result<_,_>> ।

@अर्थइंजिन

जबकि मुझे awaited कीवर्ड पर बेचा नहीं गया है, मुझे लगता है कि आप कुछ पर हैं।

यहां मुख्य अंतर्दृष्टि है: yield और await जैसे हैं return और ? ।

return x मूल्य x return 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! के पक्ष में हूं जिनका मैंने पहले वर्णन किया था। यह रस्ट-वाई और नो-बकवास लगता है।

यह समग्र पठनीयता को कम करता है, विशेष रूप से लंबी अभिव्यक्तियों या जंजीर वाले भावों के लिए।

Rustfmt मानकों में, उदाहरण लिखा जाएगा

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

मैं शायद ही देख सकता हूं कि यह पठनीयता को कैसे प्रभावित करता है।

मुझे पोस्टफिक्स का इंतजार भी पसंद है। मुझे लगता है कि एक स्थान का उपयोग करना असामान्य होगा और मानसिक समूहीकरण को तोड़ देगा। हालांकि, मुझे लगता है कि लगता है कि .await!() के साथ अच्छी तरह जोड़ी हैं, ? पहले या बाद में या तो फिटिंग, और ! नियंत्रण प्रवाह बातचीत के लिए अनुमति होगी।

(इसके लिए पूरी तरह से सामान्य पोस्टफिक्स मैक्रो तंत्र की आवश्यकता नहीं है; संकलक विशेष-मामला .await!() ।)

मैंने पोस्टफ़िक्स await (बिना . या () ) को वास्तव में दृढ़ता से नापसंद करना शुरू कर दिया क्योंकि यह बहुत अजीब लग रहा है-- अन्य भाषाओं से आने वाले लोगों को हमारे बारे में अच्छी हंसी मिलेगी निश्चित रूप से खर्च। यह एक लागत है जिसे हमें गंभीरता से लेना चाहिए। हालांकि, x await स्पष्ट रूप से फ़ंक्शन कॉल या फ़ील्ड एक्सेस नहीं है ( x.await / x.await() / await(x) सभी को यह समस्या है) और कम फंकी हैं प्राथमिकता के मुद्दे। यह वाक्यविन्यास स्पष्ट रूप से ? और विधि पहुंच प्राथमिकता को हल करेगा, उदाहरण के लिए foo await? और foo? await दोनों के पास स्पष्ट प्राथमिकता क्रम है, जैसा कि 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}}
}

मुझे अब पोस्टफ़िक्स की अपील और अधिक दिखाई दे रही है, और कुछ परिदृश्यों में इसे अधिक पसंद करने की सीमा है। विशेष रूप से उपरोक्त धोखा के साथ, जो इतना सरल है कि इसे स्वयं रस्ट द्वारा प्रदान करने की भी आवश्यकता नहीं है।

तो, पोस्टफिक्स के लिए +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! मैक्रो के संदर्भ में, उपयोगकर्ता को इसे अलग तरीके से करने के लिए अपने स्वयं के मैक्रो का आविष्कार करने से रोकने का कोई तरीका नहीं है, और रस्ट का उद्देश्य इसे सक्षम करना है। इसलिए "एक ही काम करने के कई अलग-अलग तरीकों का होना" अपरिहार्य है।

मुझे लगता है कि सरल गूंगा मैक्रो मैंने दिखाया है कि हम जो भी करते हैं, उपयोगकर्ता की इच्छा जो कुछ भी वे चाहते हैं, वैसे भी करेंगे। एक कीवर्ड, चाहे वह प्रीफ़िक्स हो या पोस्टफ़िक्स, या तो फंक्शन-जैसे प्रीफ़िक्स मैक्रो में बनाया जा सकता है, या संभवतः पोस्टफ़िक्स मेथड-जैसे मैक्रो में, जब भी वे मौजूद हों। भले ही हमने await लिए फ़ंक्शन या विधि-समान मैक्रो को चुना हो, फिर भी उन्हें एक और मैक्रो के साथ उलटा किया जा सकता है। यह वास्तव में कोई फर्क नहीं पड़ता।

इसलिए, हमें लचीलेपन और स्वरूपण पर ध्यान देना चाहिए। एक समाधान प्रदान करें जो उन सभी संभावनाओं को आसानी से भर दे।

इसके अलावा, हालांकि इस कम समय में मैं पोस्टफिक्स कीवर्ड सिंटैक्स से जुड़ गया हूं, await को जेनरेटर के साथ yield लिए जो कुछ भी तय किया गया है उसे प्रतिबिंबित करना चाहिए, जो शायद एक उपसर्ग कीवर्ड है। पोस्टफ़िक्स समाधान की इच्छा रखने वाले उपयोगकर्ताओं के लिए, विधि-जैसे मैक्रोज़ संभवतः अंततः मौजूद रहेंगे।

मेरा निष्कर्ष यह है कि एक उपसर्ग कीवर्ड await अभी के लिए सबसे अच्छा डिफ़ॉल्ट सिंटैक्स है, शायद एक नियमित टोकरा के साथ उपयोगकर्ताओं को फ़ंक्शन-जैसे await! मैक्रो प्रदान करता है, और भविष्य में एक पोस्टफ़िक्स विधि जैसी .await!() मैक्रो।

@novacrazy

इसके अलावा, हालांकि इस कम समय में मैं पोस्टफिक्स कीवर्ड सिंटैक्स से जुड़ गया हूं, await को जेनरेटर के साथ yield लिए जो कुछ भी तय किया गया है उसे मिरर करना चाहिए, जो शायद एक उपसर्ग कीवर्ड है।

अभिव्यक्ति yield 42 प्रकार पर है ! , जबकि foo.await प्रकार पर है T जहां foo: impl Future<Output = T> । @stjepang यहां ? और return साथ सही सादृश्य बनाता है। await की तरह नहीं है yield ।

क्यों न दोनों?

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

आपको मैक्रो को कुछ और नाम देना होगा क्योंकि await एक सच्चा कीवर्ड बना रहना चाहिए।

कई कारणों से, मैं await उपसर्ग का विरोध कर रहा हूं और इससे भी अधिक ब्लॉक फॉर्म await { ... } ।

सबसे पहले await expr? साथ प्राथमिकता के मुद्दे हैं जहां लगातार प्राथमिकता await (expr?) लेकिन आप (await expr)? । प्राथमिकता के मुद्दों के समाधान के रूप में, कुछ ने await expr अतिरिक्त await? expr का सुझाव दिया है। इसमें एक इकाई और विशेष आवरण के रूप में await? ; यह अनुचित लगता है, हमारे जटिल बजट की बर्बादी है, और एक संकेत है कि await expr में गंभीर समस्याएं हैं।

इससे भी महत्वपूर्ण बात, जंग कोड, और विशेष रूप से मानक पुस्तकालय डॉट और विधि कॉल सिंटैक्स की शक्ति के आसपास बहुत अधिक केंद्रित है। जब await उपसर्ग होता है, तो यह उपयोगकर्ता को केवल चेनिंग विधियों के बजाय अस्थायी लेट बाइंडिंग का आविष्कार करने के लिए प्रोत्साहित करता है। यही कारण है कि ? पोस्टफिक्स है, और इसी कारण से, await भी पोस्टफिक्स होना चाहिए।

इससे भी बुरा होगा await { ... } । यह सिंटैक्स, यदि rustfmt अनुसार लगातार स्वरूपित किया जाता है, तो इसमें बदल जाएगा:

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

यह एर्गोनोमिक नहीं होगा और कार्यों की लंबवत लंबाई को काफी कम कर देगा।

इसके बजाय, मुझे लगता है कि प्रतीक्षा करना, जैसे ? , पोस्टफिक्स होना चाहिए क्योंकि यह रस्ट इकोसिस्टम के साथ फिट बैठता है जो कि मेथड चेनिंग के आसपास केंद्रित है। कई पोस्टफिक्स सिंटैक्स का उल्लेख किया गया है; मैं उनमें से कुछ के माध्यम से जाऊंगा:

1. foo.await!() -- यह पोस्टफिक्स मैक्रो समाधान है। जबकि मैं पोस्टफिक्स मैक्रोज़ के पक्ष में हूं, मैं https://github.com/rust-lang/rust/issues/50547#issuecomment -454225040 में @cramertj से सहमत हूं कि हमें ऐसा तब तक नहीं करना चाहिए जब तक कि हम पोस्टफिक्स के लिए भी प्रतिबद्ध न हों। सामान्य रूप से मैक्रोज़। मुझे यह भी लगता है कि इस तरह से पोस्टफ़िक्स मैक्रो का उपयोग करने से एक गैर-प्रथम श्रेणी का एहसास होता है; हमें भाषा निर्माण मैक्रो सिंटैक्स का उपयोग करने से बचना चाहिए I

2. foo await - यह इतना बुरा नहीं है, यह वास्तव में एक पोस्टफिक्स ऑपरेटर ( expr op ) की तरह काम करता है लेकिन मुझे लगता है कि इस स्वरूपण के साथ कुछ गुम है (यानी यह "खाली" लगता है); इसके विपरीत, expr? ? सीधे expr पर जोड़ता है; यहाँ कोई जगह नहीं है। यह ? देखने में आकर्षक बनाता है।

3. foo.await -- फील्ड एक्सेस की तरह दिखने के लिए इसकी आलोचना की गई है; और यह सच है। हालांकि हमें याद रखना चाहिए कि await एक कीवर्ड है और इस प्रकार इसे सिंटैक्स हाइलाइट किया जाएगा। यदि आप अपने IDE में या GitHub पर समकक्ष रूप से Rust कोड पढ़ते हैं, तो await foo से भिन्न रंग या बोल्डनेस में होगा। किसी भिन्न कीवर्ड का उपयोग करके हम इसे प्रदर्शित कर सकते हैं:

   let x = foo.match?;
   

   प्रथागत रूप से, फ़ील्ड भी संज्ञा हैं जबकि await एक क्रिया है।

   जबकि foo.await बारे में प्रारंभिक उपहास कारक है, मुझे लगता है कि इसे पठनीय वाक्यविन्यास के साथ-साथ एक दृष्टि से आकर्षक के रूप में गंभीर विचार दिया जाना चाहिए।

   एक बोनस के रूप में, .await से आपको डॉट की शक्ति मिलती है और डॉट को आमतौर पर आईडीई में स्वत: पूर्णता मिलती है (पृष्ठ 56 देखें)। उदाहरण के लिए, आप foo. लिख सकते हैं और यदि foo भविष्य होता है, तो await पहली पसंद के रूप में दिखाया जाएगा। यह एर्गोनॉमिक्स और डेवलपर उत्पादकता दोनों की सुविधा देता है क्योंकि डॉट तक पहुंचने के लिए कई डेवलपर्स ने मांसपेशियों की स्मृति में प्रशिक्षित किया है।

   सभी संभावित पोस्टफ़िक्स सिंटैक्स में, फ़ील्ड एक्सेस की तरह दिखने की आलोचना के बावजूद, यह मेरा पसंदीदा सिंटैक्स बना हुआ है।

4. foo# - sigil इस का उपयोग करता है # पर इंतजार foo । मुझे लगता है कि एक सतर्क पर विचार करना एक अच्छा विचार है क्योंकि ? भी एक सतर्क है और क्योंकि यह हल्के वजन का इंतजार कर रहा है। ? साथ संयुक्त यह foo#? जैसा दिखेगा -- जो ठीक दिखता है। हालांकि, # का कोई विशिष्ट औचित्य नहीं है। बल्कि, यह केवल एक सतर्क है जो अभी भी उपलब्ध है।

5. foo@ -- एक और सावधानी है @ । ? के साथ संयुक्त होने पर, हमें foo@? । इस विशिष्ट सतर्कता का एक औचित्य यह है कि यह a -ish ( @wait ) दिखता है।

6. foo! -- अंत में, ! । ? के साथ संयुक्त होने पर, हमें foo!? । दुर्भाग्य से, इसमें एक निश्चित डब्ल्यूटीएफ भावना है। हालांकि, ! मूल्य को मजबूर करने जैसा दिखता है, जो "प्रतीक्षा" फिट बैठता है। इसमें एक कमी है कि foo!() पहले से ही एक कानूनी मैक्रो आमंत्रण है, इसलिए किसी फ़ंक्शन की प्रतीक्षा करने और कॉल करने के लिए (foo)!() । सिंटैक्स के रूप में foo! का उपयोग करने से हमें कीवर्ड मैक्रोज़ (जैसे foo! expr ) प्राप्त करने का अवसर भी समाप्त हो जाएगा।

एक और सिंगल सिगिल है foo~ । लहर को "गूंज" या "समय लगता है" के रूप में समझा जा सकता है। फिर भी रस्ट भाषा में कहीं भी इसका प्रयोग नहीं होता है।

टिल्डे ~ का उपयोग पुराने दिनों में ढेर आवंटित प्रकार के लिए किया जाता था: https://github.com/rust-lang/rfcs/blob/master/text/0059-remove-tilde.md

क्या ? का पुन: उपयोग किया जा सकता है? या यह बहुत ज्यादा जादू है? impl Try for T: Future कैसा दिखेगा?

@parasyte हाँ मुझे याद है। लेकिन फिर भी यह लंबा चला गया था।

@jethrogb कोई रास्ता नहीं है कि मैं impl Try सीधे काम करते हुए देख सकता हूं, ? स्पष्ट रूप से return वर्तमान फ़ंक्शन से Try का परिणाम है जबकि await को yield ।

हो सकता है ? को जनरेटर के संदर्भ में कुछ और करने के लिए विशेष-आवरण किया जा सकता है ताकि यह या तो yield या return उस अभिव्यक्ति के प्रकार के आधार पर हो सके जिस पर इसे लागू किया गया है , लेकिन मुझे यकीन नहीं है कि यह कितना समझ में आता है। इसके अलावा कैसे साथ कि बातचीत Future<Output=Result<...>> , आप करने के लिए होगा let foo = bar()??; दोनों को है "इंतजार" और फिर मिल Ok के संस्करण Result ( या जेनरेटर में ? एक ट्रिस्टेट विशेषता पर आधारित होगा जो yield , return या एक ही एप्लिकेशन के साथ एक मूल्य को हल कर सकता है)?

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 के पुन: उपयोग के संबंध में मेरा भी यही विचार था।

@ निमो157

ऐसा कोई तरीका नहीं है जिससे मैं impl Try सीधे काम करते हुए देख सकूं, ? स्पष्ट रूप से return s वर्तमान फ़ंक्शन से Try का परिणाम है जबकि प्रतीक्षा को yield ।

शायद मुझे ? और Try विशेषता पर कुछ विवरण याद आ रहे हैं, लेकिन यह कहां/क्यों स्पष्ट है? और एक एसिंक क्लोजर में return अनिवार्य रूप से yield के समान ही नहीं है, बस एक अलग राज्य संक्रमण है?

हो सकता है ? को जनरेटर के संदर्भ में कुछ और करने के लिए विशेष-आवरण किया जा सकता है ताकि यह या तो yield या return उस अभिव्यक्ति के प्रकार के आधार पर हो सके जिस पर इसे लागू किया गया है , लेकिन मुझे यकीन नहीं है कि यह कितना समझ में आता है।

मुझे नहीं लगता कि यह भ्रमित क्यों होना चाहिए। यदि आप ? को "जारी रखें या अलग करें" के रूप में सोचते हैं, तो यह स्वाभाविक लगता है, IMHO। दी, संबंधित रिटर्न प्रकारों के लिए अलग-अलग नामों का उपयोग करने के लिए Try विशेषता को बदलने से मदद मिलेगी।

साथ ही यह Future<Output=Result<...>> साथ कैसे इंटरैक्ट करेगा, क्या आपको let foo = bar()?? ;

यदि आप परिणाम की प्रतीक्षा करना चाहते हैं और फिर त्रुटि परिणाम पर जल्दी बाहर निकलना चाहते हैं, तो वह तार्किक अभिव्यक्ति होगी, हाँ। मुझे नहीं लगता कि एक विशेष त्रि-राज्य TryGen की बिल्कुल भी आवश्यकता होगी।

दुर्भाग्य से मैं नहीं देखता कि इस तरह की योजना में वेकर संदर्भ चर को कैसे संभालना है, शायद अगर? जनरेटर के बजाय एसिंक के लिए विशेष-आवरण थे, लेकिन यदि यह यहां विशेष-आवरण होने जा रहा है तो यह अच्छा होगा यदि यह अन्य जेनरेटर उपयोग-मामलों के लिए उपयोग योग्य हो।

मुझे यह हिस्सा समझ में नहीं आ रहा है। क्या आप विस्तृत कर सकते हैं?

@jethrogb @rolandsteiner एक संरचना Try और Future दोनों को लागू कर सकती है। इस मामले में, कौन सा ? खोलना चाहिए?

@jethrogb @rolandsteiner एक संरचना कोशिश और भविष्य दोनों को लागू कर सकती है। इस मामले में, कौन सा करना चाहिए? खोलना?

नहीं, यह कंबल के कारण नहीं हो सकता है T: Future के लिए प्रयास करें।

कोई स्पष्ट निर्माण और निहित प्रतीक्षित प्रस्ताव के बारे में बात क्यों नहीं कर रहा है? यह सिंक io के बराबर है, बस यह थ्रेड के बजाय टास्क को ब्लॉक कर रहा है। मैं यह भी कहूंगा कि किसी कार्य को अवरुद्ध करने से थ्रेड को अवरुद्ध करना अधिक आक्रामक है, तो थ्रेड-ब्लॉकिंग-आईओ के लिए कोई विशेष "प्रतीक्षा" वाक्यविन्यास क्यों नहीं है?

लेकिन यह सब सिर्फ बाइक छायांकन है, मुझे लगता है कि हमें कम से कम अभी के लिए सरल मैक्रो सिंटैक्स await!(my_future) लिए समझौता करना चाहिए

लेकिन यह सब सिर्फ बाइक छायांकन है, मुझे लगता है कि हमें कम से कम अभी के लिए सरल मैक्रो सिंटैक्स await!(my_future) लिए समझौता करना चाहिए

नहीं, यह "बस" बाइक-शेडिंग नहीं है जैसे कि यह कुछ सामान्य और महत्वहीन था। क्या await उपसर्ग लिखा है या पोस्टफिक्स मौलिक रूप से प्रभावित करता है कि कैसे async कोड wrt लिखा जाता है। विधि श्रृखंला और यह कितना अनुकूल लगता है। await!(future) पर स्थिर होने का मतलब यह भी है कि कीवर्ड के रूप में await को छोड़ दिया जाता है जो भविष्य में कीवर्ड के रूप में await को असंभव बना देता है। "कम से कम अभी के लिए" यह सुझाव देता है कि हम बाद में एक बेहतर वाक्यविन्यास ढूंढ सकते हैं और इसमें शामिल तकनीकी ऋण की अवहेलना कर सकते हैं। मैं जानबूझकर ऋण को एक वाक्य रचना के लिए पेश करने का विरोध कर रहा हूं जिसे बाद में बदला जाना है।

प्रतीक्षा! (भविष्य) पर स्थिरीकरण में यह भी शामिल है कि एक खोजशब्द के रूप में प्रतीक्षा को छोड़ दिया जाता है जो भविष्य में एक खोजशब्द के रूप में प्रतीक्षा के उपयोग को असंभव बना देता है।

हम इसे अगले युग में एक कीवर्ड बना सकते हैं, जिसमें मैक्रो के लिए कच्चे पहचान सिंटैक्स की आवश्यकता होती है, जैसा कि हमने try साथ किया था।

@chpio await पहले से ही Rust 2018 में एक कीवर्ड है।

@rolandsteiner

और एक एसिंक क्लोजर में return अनिवार्य रूप से yield के समान ही नहीं है, बस एक अलग राज्य संक्रमण है?

yield एक एसिंक क्लोजर में मौजूद नहीं है, यह async / await सिंटैक्स से जनरेटर/ yield को कम करने के दौरान शुरू किया गया एक ऑपरेशन है। वर्तमान जनरेटर सिंटैक्स में yield से काफी अलग है return , अगर ? विस्तार जनरेटर परिवर्तन से पहले किया जाता है तो मुझे नहीं पता कि यह कैसे पता चलेगा कि कब सम्मिलित करना है एक return या एक yield ।

यदि आप परिणाम की प्रतीक्षा करना चाहते हैं और त्रुटि परिणाम पर भी जल्दी बाहर निकलना चाहते हैं, तो वह तार्किक अभिव्यक्ति होगी, हाँ।

यह तार्किक हो सकता है, लेकिन यह मेरे लिए एक नकारात्मक पहलू की तरह लगता है कि बहुत सारे (अधिकांश?) मामले जहां आप async फ़ंक्शन लिख रहे हैं, IO त्रुटियों से निपटने के लिए डबल ?? से भरे जाएंगे।

दुर्भाग्य से मैं नहीं देखता कि वेकर संदर्भ चर को कैसे संभालना है ...

मुझे यह हिस्सा समझ में नहीं आ रहा है। क्या आप विस्तृत कर सकते हैं?

async ट्रांसफ़ॉर्म जेनरेट किए गए Future::poll फ़ंक्शन में एक वेकर वैरिएबल में लेता है, इसके बाद इसे ट्रांसफ़ॉर्म किए गए प्रतीक्षित ऑपरेशन में पास करने की आवश्यकता होती है। वर्तमान में इसे std द्वारा प्रदान किए गए एक TLS चर के साथ नियंत्रित किया जाता है, जो दोनों संदर्भ को बदल देता है, यदि ? को इसके बजाय एक पुन: उपज बिंदु के रूप में संभाला जाता है _at जनरेटर स्तर_ तो async परिवर्तन एक तरह से खो जाता है इस परिवर्तनीय संदर्भ को सम्मिलित करने के लिए।

मैंने await सिंटैक्स के बारे में दो महीने पहले की अपनी वरीयता को रेखांकित करते हुए एक ब्लॉग पोस्ट लिखा था। हालांकि, यह मूल रूप से एक उपसर्ग वाक्यविन्यास माना जाता है, और उस परिप्रेक्ष्य से केवल प्राथमिकता मुद्दा माना जाता है। यहाँ अब कुछ अतिरिक्त विचार हैं:

• मेरी सामान्य राय यह है कि रस्ट ने वास्तव में अपने अपरिचित बजट को पहले ही बढ़ा दिया है। सतह के स्तर के लिए यह आदर्श होगा कि जावास्क्रिप्ट या पायथन या सी # से आने वाले किसी व्यक्ति से जितना संभव हो उतना परिचित होना चाहिए। इस दृष्टिकोण से आदर्श से केवल मामूली तरीकों से विचलन करना आदर्श होगा। पोस्टफ़िक्स सिंटैक्स इस बात पर भिन्न होता है कि वे कितनी दूर हैं (उदाहरण के लिए foo await कुछ सतर्क की तुलना में एक विचलन से कम है foo@ ), लेकिन वे सभी उपसर्ग प्रतीक्षा से अधिक भिन्न हैं।
• मैं एक सिंटैक्स को स्थिर करना भी पसंद करता हूं जो ! उपयोग नहीं करता है। एसिंक/प्रतीक्षा से निपटने वाले प्रत्येक उपयोगकर्ता को आश्चर्य होगा कि सामान्य नियंत्रण प्रवाह निर्माण के बजाय प्रतीक्षा मैक्रो क्यों है, और मेरा मानना ​​​​है कि यहां कहानी अनिवार्य रूप से होगी "अच्छी तरह से हम एक अच्छा वाक्यविन्यास नहीं समझ सके इसलिए हम बस बस गए यह एक मैक्रो की तरह दिखता है।" यह एक सम्मोहक उत्तर नहीं है। मुझे नहीं लगता कि ! और नियंत्रण प्रवाह के बीच संबंध वास्तव में इस सिंटैक्स को सही ठहराने के लिए पर्याप्त है: मेरा मानना ​​​​है कि ! का अर्थ विशेष रूप से मैक्रो विस्तार है, जो यह नहीं है।
• मैं सामान्य रूप से पोस्टफिक्स प्रतीक्षा के लाभ के बारे में संदिग्ध हूं (पूरी तरह से नहीं, बस प्रकार )। मुझे लगता है कि शेष राशि ? से थोड़ी अलग है, क्योंकि प्रतीक्षा करना एक अधिक महंगा ऑपरेशन है (आप इसके तैयार होने तक एक लूप में उपज देते हैं, बजाय केवल ब्रांचिंग और एक बार लौटने के)। मुझे उस कोड पर संदेह है जो एक ही अभिव्यक्ति में दो या तीन बार प्रतीक्षा करेगा; मुझे यह कहना ठीक लगता है कि इन्हें अपने स्वयं के लेट बाइंडिंग में खींच लिया जाना चाहिए। तो try! बनाम ? व्यापार बंद मुझे यहां उतनी मजबूती से नहीं खींचता है। लेकिन साथ ही, मैं कोड नमूने के लिए खुला रहूंगा जो लोगों को लगता है कि वास्तव में लेट्स में नहीं खींचा जाना चाहिए और विधि श्रृंखला के रूप में स्पष्ट है।

उस ने कहा, foo await सबसे व्यवहार्य पोस्टफिक्स सिंटैक्स है जिसे मैंने अब तक देखा है:

• यह पोस्टफिक्स सिंटैक्स के लिए अपेक्षाकृत परिचित है। आपको बस इतना सीखना है कि रस्ट में पहले के बजाय प्रतीक्षा अभिव्यक्ति के बाद जाती है, न कि अलग-अलग सिंटैक्स के बजाय।
• यह उस प्राथमिकता के मुद्दे को स्पष्ट रूप से हल करता है जिसके बारे में यह सब रहा है।
• तथ्य यह है कि यह विधि श्रृंखला के साथ अच्छी तरह से काम नहीं करता है, मुझे पहले से बताए गए कारणों से नुकसान के बजाय लगभग एक लाभ की तरह लगता है। मैं और अधिक मजबूर हो सकता हूं यदि हमारे पास कुछ व्याकरण नियम हैं जो 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;

यह बिल्कुल आदर्श नहीं है, लेकिन यह देखते हुए कि यह एक ही पंक्ति में बहुत अधिक रटने की कोशिश कर रहा है, मुझे लगता है कि यह उचित है।

और जैसा कि @earthengine पहले उल्लेख किया गया है, बहु-पंक्ति संस्करण बहुत ही उचित है (कोई अतिरिक्त

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

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

• सतह के स्तर के लिए यह आदर्श होगा कि जावास्क्रिप्ट या पायथन या सी # से आने वाले किसी व्यक्ति से जितना संभव हो उतना परिचित होना चाहिए।

try { .. } के मामले में, हमने अन्य भाषाओं से परिचित होने को ध्यान में रखा। हालाँकि, यह रस्ट के साथ आंतरिक स्थिरता के POV से भी सही डिज़ाइन था। तो उन अन्य भाषाओं के लिए पूरे सम्मान के साथ, जंग में आंतरिक स्थिरता अधिक महत्वपूर्ण लगती है और मुझे नहीं लगता कि उपसर्ग वाक्यविन्यास या तो प्राथमिकता के संदर्भ में या एपीआई कैसे संरचित किया जाता है, में जंग फिट बैठता है।

• मैं एक सिंटैक्स को स्थिर करना भी पसंद करता हूं जो ! उपयोग नहीं करता है। एसिंक/प्रतीक्षा से निपटने वाले प्रत्येक उपयोगकर्ता को आश्चर्य होगा कि सामान्य नियंत्रण प्रवाह निर्माण के बजाय प्रतीक्षा मैक्रो क्यों है, और मेरा मानना ​​​​है कि यहां कहानी अनिवार्य रूप से होगी "अच्छी तरह से हम एक अच्छा वाक्यविन्यास नहीं समझ सके इसलिए हम बस बस गए यह एक मैक्रो की तरह दिखता है।" यह एक सम्मोहक उत्तर नहीं है।

मैं इस भावना से सहमत हूं, .await!() पर्याप्त प्रथम श्रेणी का नहीं लगेगा।

• मैं सामान्य रूप से पोस्टफिक्स प्रतीक्षा के लाभ के बारे में संदिग्ध हूं (पूरी तरह से नहीं, केवल _sort of_)। मुझे लगता है कि शेष राशि ? से थोड़ी अलग है, क्योंकि प्रतीक्षा करना एक अधिक महंगा ऑपरेशन है (आप इसके तैयार होने तक एक लूप में उपज देते हैं, बजाय केवल ब्रांचिंग और एक बार लौटने के)।

मैं नहीं देखता कि चीजों को let बाइंडिंग में निकालने के साथ क्या महंगाता है। मेथड चेन कभी-कभी महंगी भी हो सकती हैं और महंगी भी। let बाइंडिंग का लाभ यह है कि a) पर्याप्त रूप से बड़े टुकड़ों को एक ऐसा नाम दें जहां यह पठनीयता को बढ़ाने के लिए समझ में आता है, b) एक ही गणना मूल्य को एक से अधिक बार संदर्भित करने में सक्षम होना (जैसे &x या जब कोई प्रकार कॉपी करने योग्य हो)।

मुझे उस कोड पर संदेह है जो एक ही अभिव्यक्ति में दो या तीन बार प्रतीक्षा करेगा; मुझे यह कहना ठीक लगता है कि इन्हें अपने स्वयं के लेट बाइंडिंग में खींच लिया जाना चाहिए।

यदि आपको लगता है कि उन्हें अपने स्वयं के let बाइंडिंग में खींच लिया जाना चाहिए, तो भी आप पोस्टफिक्स await साथ वह विकल्प चुन सकते हैं:

let temporary = some_computation() await?;

उन लोगों के लिए जो असहमत हैं और मेथड चेनिंग पसंद करते हैं, पोस्टफिक्स await चुनने की क्षमता देता है। मुझे यह भी लगता है कि पोस्टफिक्स यहां बाएं से दाएं पढ़ने और डेटा-फ्लो ऑर्डर का बेहतर पालन करता है, भले ही आप let बाइंडिंग में निकालें तो भी मैं पोस्टफिक्स को पसंद करूंगा।

मैं यह भी नहीं सोचता कि उपयोगी होने के लिए आपको पोस्टफिक्स await लिए दो या तीन बार प्रतीक्षा करने की आवश्यकता है। उदाहरण के लिए विचार करें (यह rustfmt का परिणाम है):

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

लेकिन साथ ही, मैं कोड नमूने के लिए खुला रहूंगा जो लोगों को लगता है कि वास्तव में लेट्स में नहीं खींचा जाना चाहिए और विधि श्रृंखला के रूप में स्पष्ट है।

let बाइंडिंग में और let binding = await!(...)?; साथ निकाले जाने पर मैंने पढ़ा अधिकांश फ्यूशिया कोड अप्राकृतिक महसूस किया।

• यह पोस्टफिक्स सिंटैक्स के लिए अपेक्षाकृत परिचित है। आपको बस इतना सीखना है कि रस्ट में पहले के बजाय प्रतीक्षा अभिव्यक्ति के बाद जाती है, न कि अलग-अलग सिंटैक्स के बजाय।

यहां foo.await लिए मेरी प्राथमिकता मुख्य रूप से इसलिए है क्योंकि आपको अच्छी स्वतः पूर्णता और बिंदु की शक्ति मिलती है। यह इतना मौलिक रूप से अलग भी नहीं लगता है। foo.await.method() लिखने से यह भी स्पष्ट हो जाता है कि .method() को foo.await लागू किया जाता है। तो यह उस चिंता का समाधान करता है।

• यह उस प्राथमिकता के मुद्दे को स्पष्ट रूप से हल करता है जिसके बारे में यह सब रहा है।

नहीं, यह केवल वरीयता के बारे में नहीं है। विधि श्रृंखला समान रूप से महत्वपूर्ण हैं।

• तथ्य यह है कि यह विधि श्रृंखला के साथ अच्छी तरह से काम नहीं करता है, मुझे पहले से बताए गए कारणों से नुकसान के बजाय लगभग एक लाभ की तरह लगता है।

मुझे यकीन नहीं है कि यह विधि श्रृंखला के साथ अच्छी तरह से काम क्यों नहीं करता है।

मैं और अधिक मजबूर हो सकता हूं यदि हमारे पास कुछ व्याकरण नियम हैं जो foo await.method() रोकते हैं, क्योंकि मुझे वास्तव में लगता है कि विधि await लागू की जा रही है, न कि foo (जबकि दिलचस्प बात यह है कि मुझे नहीं लगता कि foo await? )।

जबकि मुझे foo await साथ जाने के लिए बाध्य नहीं किया जाएगा यदि हम एक जानबूझकर डिजाइन पेपरकट पेश करते हैं और पोस्टफिक्स await सिंटैक्स के साथ चेनिंग को रोकते हैं।

यह मानते हुए कि हर विकल्प में एक नकारात्मक पहलू है, और उनमें से एक को फिर भी चुना जाना चाहिए ... एक बात जो मुझे foo.await बारे में परेशान करती है, वह यह है कि, भले ही हम यह मान लें कि यह सचमुच गलत नहीं होगा एक स्ट्रक्चर फ़ील्ड, यह अभी भी एक स्ट्रक्चर फ़ील्ड तक पहुंचने जैसा दिखता है । फील्ड एक्सेस का अर्थ यह है कि कुछ भी विशेष रूप से प्रभावशाली नहीं हो रहा है - यह रस्ट में सबसे कम प्रभावी संचालन में से एक है। इस बीच प्रतीक्षा करना अत्यधिक प्रभावशाली है, सबसे अधिक साइड-इफ़ेक्टिंग ऑपरेशनों में से एक (यह दोनों भविष्य में निर्मित I/O संचालन करता है और नियंत्रण प्रवाह प्रभाव रखता है)। इसलिए जब मैं foo.await.method() पढ़ता हूं, तो मेरा दिमाग मुझे .await से अधिक छोड़ने के लिए कह रहा है क्योंकि यह अपेक्षाकृत दिलचस्प नहीं है, और मुझे उस वृत्ति को मैन्युअल रूप से ओवरराइड करने के लिए ध्यान और प्रयास का उपयोग करना होगा।

यह अभी भी _लगता है_ एक स्ट्रक्चर फ़ील्ड तक पहुंच रहा है।

@glaebhoerl आप अच्छे अंक बनाते हैं; हालांकि, सिंटैक्स हाइलाइटिंग का यह कैसा दिखता है और जिस तरह से आपका मस्तिष्क चीजों को संसाधित करता है, उस पर कोई/अपर्याप्त प्रभाव नहीं पड़ता है? कोड पढ़ते समय कम से कम मेरे लिए रंग और बोल्डनेस बहुत मायने रखती है इसलिए मैं .await से अधिक नहीं छोड़ूंगा जिसमें बाकी चीजों की तुलना में एक अलग रंग है।

फील्ड एक्सेस का अर्थ यह है कि कुछ भी विशेष रूप से प्रभावशाली नहीं हो रहा है - यह रस्ट में सबसे कम प्रभावी संचालन में से एक है। इस बीच प्रतीक्षा करना अत्यधिक प्रभावशाली है, सबसे अधिक साइड-इफ़ेक्टिंग ऑपरेशनों में से एक (यह दोनों भविष्य में निर्मित I/O संचालन करता है और इसमें नियंत्रण प्रवाह प्रभाव होता है)।

मैं इससे दृढ़ता से सहमत हूं। await एक नियंत्रण प्रवाह ऑपरेशन है जैसे break या return , और स्पष्ट होना चाहिए। प्रस्तावित पोस्टफिक्स संकेतन अप्राकृतिक लगता है, जैसे कि पायथन का if : if c { e1 } else { e2 } से e1 if c else e2 । अंत में ऑपरेटर को देखने से आप किसी भी सिंटैक्स हाइलाइटिंग की परवाह किए बिना डबल-टेक करते हैं।

मैं यह भी नहीं देखता कि कैसे e.await रस्ट सिंटैक्स के साथ await!(e) या await e तुलना में अधिक संगत है। कोई अन्य पोस्टफ़िक्स कीवर्ड नहीं है, और चूंकि विचारों में से एक इसे पार्सर में विशेष-केस करना था, मुझे नहीं लगता कि यह सुसंगत होने का प्रमाण है।

@withboats का उल्लेख परिचित समस्या भी है। हम अजीब और अद्भुत वाक्य रचना चुन सकते हैं यदि इसके कुछ अद्भुत लाभ हैं। क्या एक पोस्टफिक्स await उनके पास है, यद्यपि?

क्या सिंटैक्स हाइलाइटिंग का यह कैसा दिखता है और जिस तरह से आपका मस्तिष्क चीजों को संसाधित करता है, उस पर कोई/अपर्याप्त प्रभाव नहीं डालता है?

(अच्छा सवाल है, मुझे यकीन है कि इसका कुछ असर होगा, लेकिन यह अनुमान लगाना मुश्किल है कि वास्तव में इसे आजमाए बिना कितना (और एक अलग कीवर्ड को प्रतिस्थापित करना केवल इतना ही हो जाता है)। जबकि हम इस विषय पर हैं ... एक लंबा समय पहले मैंने उल्लेख किया था कि मुझे लगता है कि सिंटैक्स हाइलाइटिंग को नियंत्रण प्रवाह प्रभाव वाले सभी ऑपरेटरों को हाइलाइट करना चाहिए ( return , break , continue , ? ... और अब await ) कुछ विशेष अतिरिक्त-विशिष्ट रंग में, लेकिन मैं किसी भी चीज़ के लिए सिंटैक्स हाइलाइटिंग का प्रभारी नहीं हूं और मुझे नहीं पता कि कोई वास्तव में ऐसा करता है या नहीं।)

मैं इससे दृढ़ता से सहमत हूं। await एक नियंत्रण प्रवाह ऑपरेशन है जैसे break या return , और स्पष्ट होना चाहिए।

हम मानते हैं। नोटेशन foo.await , foo await , foo# , ... स्पष्ट हैं । कोई निहित प्रतीक्षा नहीं की जा रही है।

मैं यह भी नहीं देखता कि कैसे e.await रस्ट सिंटैक्स के साथ await!(e) या await e तुलना में अधिक संगत है।

सिंटैक्स e.await प्रति से रस्ट सिंटैक्स के अनुरूप नहीं है, लेकिन पोस्टफ़िक्स आमतौर पर ? साथ बेहतर फिट बैठता है और रस्ट एपीआई को कैसे संरचित किया जाता है (तरीकों को मुफ्त कार्यों पर पसंद किया जाता है)।

await e? सिंटैक्स, यदि (await e)? रूप में संबद्ध है, तो break और return सहयोगी के साथ पूरी तरह से असंगत है। await!(e) भी असंगत है क्योंकि हमारे पास नियंत्रण प्रवाह के लिए मैक्रोज़ नहीं हैं और इसमें अन्य उपसर्ग विधियों की तरह ही समस्या है।

कोई अन्य पोस्टफ़िक्स कीवर्ड नहीं है, और चूंकि विचारों में से एक इसे पार्सर में विशेष-केस करना था, मुझे नहीं लगता कि यह सुसंगत होने का प्रमाण है।

मुझे नहीं लगता कि आपको वास्तव में .await लिए libsyntax को बदलने की जरूरत है क्योंकि इसे पहले से ही एक फील्ड ऑपरेशन के रूप में संभाला जाना चाहिए। तर्क को इसके बजाय संकल्प या एचआईआर में निपटाया जाएगा जहां आप इसे एक विशेष निर्माण में अनुवादित करते हैं।

हम अजीब और अद्भुत वाक्य रचना चुन सकते हैं यदि इसके कुछ अद्भुत लाभ हैं। क्या एक पोस्टफिक्स await उनके पास है, यद्यपि?

जैसा कि ऊपर उल्लेख किया गया है, मेरा तर्क है कि यह मेथड चेनिंग और रस्ट की मेथड कॉल के लिए वरीयता के कारण होता है।

मुझे नहीं लगता कि आपको वास्तव में .wait के लिए 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 तुलना में कोड में अधिक दिखाई देगा।

मेरा तर्क है कि यह मेथड चेनिंग और रस्ट की मेथड कॉल के लिए वरीयता के कारण होता है।

इसमें उपसर्ग नियंत्रण प्रवाह ऑपरेटरों के लिए एक (अधिक ध्यान देने योग्य) वरीयता भी है।

प्रतीक्षा ई? सिंटैक्स, यदि (प्रतीक्षा ई) के रूप में संबद्ध है? कैसे ब्रेक और रिटर्न सहयोगी के साथ पूरी तरह से असंगत है।

मुझे पसंद है await!(e)? , await { e }? या शायद { await e }? - मुझे नहीं लगता कि मैंने बाद में चर्चा की है, और मुझे यकीन नहीं है कि यह काम करता है।

मैं मानता हूं कि बाएं से दाएं पूर्वाग्रह हो सकते हैं। _ध्यान दें_

इस पर मेरी राय हर बार इस मुद्दे को देखने पर बदल जाती है, जैसे कि मैं खुद के लिए डेविल्स एडवोकेट की भूमिका निभा रहा हूं। इसका एक कारण यह है कि मुझे अपना फ्यूचर और स्टेट मशीन लिखने की आदत हो गई है। poll साथ एक कस्टम भविष्य पूरी तरह से सामान्य है।

शायद इसे दूसरे तरीके से सोचा जाना चाहिए।

मेरे लिए, रस्ट में शून्य-लागत सार दो चीजों को संदर्भित करता है: रनटाइम पर शून्य-लागत, और अधिक महत्वपूर्ण रूप से शून्य-लागत मानसिक रूप से।

मैं वायदा सहित जंग में अधिकांश अमूर्तताओं के बारे में आसानी से तर्क कर सकता हूं, क्योंकि वे सिर्फ राज्य मशीन हैं।

यह अंत करने के लिए, एक सरल समाधान मौजूद होना चाहिए जो उपयोगकर्ता को थोड़ा जादू के रूप में पेश करता है। सिगिल विशेष रूप से एक बुरा विचार है, क्योंकि वे अनावश्यक रूप से जादुई महसूस करते हैं। इसमें .await जादू के क्षेत्र शामिल हैं।

शायद सबसे अच्छा समाधान सबसे आसान है, मूल await! मैक्रो।

तो उन अन्य भाषाओं के लिए पूरे सम्मान के साथ, जंग में आंतरिक स्थिरता अधिक महत्वपूर्ण लगती है और मुझे नहीं लगता कि उपसर्ग वाक्यविन्यास या तो प्राथमिकता के संदर्भ में या एपीआई कैसे संरचित किया जाता है, में जंग फिट बैठता है।

मैं नहीं देखता कैसे...? await(foo)? / await { foo }? ऑपरेटर वरीयता के मामले में पूरी तरह से ठीक लगता है और एपीआई को रस्ट में कैसे संरचित किया जाता है- इसका नकारात्मक पक्ष माता-पिता की शब्दशःता है और (आपके दृष्टिकोण के आधार पर) जंजीर, मिसाल को तोड़ना या होना नहीं है भ्रमित करने वाला।

try! (जिसने अपने उद्देश्य को बहुत अच्छी तरह से पूरा किया) और तर्कसंगत रूप से बहिष्कृत select! ।

मुझे लगता है कि यहां ऑपरेटिव शब्द बहिष्कृत है । रस्ट 2018 पर try!(...) का उपयोग करना एक कठिन त्रुटि है। यह अब एक कठिन त्रुटि है क्योंकि हमने एक बेहतर, प्रथम श्रेणी और पोस्टफ़िक्स सिंटैक्स पेश किया है।

ध्यान दें कि await return तुलना में "मजबूत" है, इसलिए यह अपेक्षा करना अनुचित नहीं है कि यह ? के return तुलना में कोड में अधिक दिखाई देगा।

? ऑपरेटर भी साइड-इफेक्टिंग हो सकता है ( Result अलावा अन्य कार्यान्वयन के माध्यम से) और नियंत्रण प्रवाह करता है इसलिए यह काफी "मजबूत" भी है। जब इस पर चर्चा की गई, तो ? पर "वापसी को छिपाने" और अनदेखी करने में आसान होने का आरोप लगाया गया। मुझे लगता है कि भविष्यवाणी सच होने में पूरी तरह विफल रही। स्थिति पुन. await मेरे जैसा ही लगता है।

इसमें उपसर्ग नियंत्रण प्रवाह ऑपरेटरों के लिए एक (अधिक ध्यान देने योग्य) वरीयता भी है।

उन उपसर्ग नियंत्रण प्रवाह ऑपरेटरों को ! प्रकार पर टाइप किया जाता है। इस बीच, अन्य नियंत्रण प्रवाह ऑपरेटर ? जो एक संदर्भ impl Try<Ok = T, ...> लेता है और आपको T है वह पोस्टफिक्स है।

मैं नहीं देखता कैसे...? await(foo)? / await { foo }? ऑपरेटर वरीयता के मामले में पूरी तरह से ठीक लगता है और कैसे एपीआई को जंग में संरचित किया जाता है-

await(foo) सिंटैक्स await foo के समान नहीं है यदि कोष्ठक पूर्व के लिए आवश्यक है और बाद के लिए नहीं। पूर्व अभूतपूर्व है, बाद वाले में वरीयता के मुद्दे हैं। ? जैसा कि हमने यहां चर्चा की है, नाव के ब्लॉग पोस्ट पर और डिस्कॉर्ड पर। await { foo } सिंटैक्स अन्य कारणों से समस्याग्रस्त है (देखें https://github.com/rust-lang/rust/issues/50547#issuecomment-454313611)।

इसका नकारात्मक पक्ष माता-पिता की शब्दशःता और (आपके दृष्टिकोण के आधार पर) जंजीर बनाना है, न कि मिसाल को तोड़ना या भ्रमित करना।

"एपीआई संरचित हैं" से मेरा यही मतलब है। मुझे लगता है कि रस्ट में तरीके और मेथड चेनिंग आम और मुहावरेदार हैं। उपसर्ग और ब्लॉक सिंटैक्स उन लोगों के साथ और ? साथ खराब रचना करते हैं।

मैं इस राय के साथ अल्पमत में हो सकता हूं, और यदि ऐसा है, तो मुझे अनदेखा करें:

क्या उपसर्ग-बनाम-पोस्टफ़िक्स चर्चा को आंतरिक थ्रेड में ले जाना उचित होगा, और फिर परिणाम के साथ यहां वापस आएं? इस तरह हम ट्रैकिंग समस्या को फीचर की स्थिति को

@seanmonstar हाँ, मैं ट्रैकिंग मुद्दों पर चर्चा को सीमित करने की इच्छा के साथ दृढ़ता से सहानुभूति रखता हूं और ऐसे मुद्दे हैं जो वास्तव में केवल स्थिति अपडेट हैं। यह उन मुद्दों में से एक है जो मुझे आशा है कि हम कुछ संशोधनों से निपट सकते हैं कि हम आरएफसी प्रक्रिया और सामान्य रूप से मुद्दों को कैसे प्रबंधित करते हैं। अभी के लिए, मैंने चर्चा के लिए उपयोग करने के लिए यहां एक नया मुद्दा खोला है।

सभी के लिए महत्वपूर्ण: आगे await सिंटैक्स चर्चा यहां होनी चाहिए।

यह सुनिश्चित करने के लिए एक दिन के लिए अस्थायी रूप से लॉक करना कि उचित मुद्दे पर await सिंटैक्स के बारे में भविष्य की चर्चा हो।

मंगलवार, 15 जनवरी, 2019 को 07:10:32 पूर्वाह्न -800 बजे, पौन ने लिखा:

सिडेनोट: प्राथमिकता को स्पष्ट करने के लिए माता-पिता का उपयोग करना हमेशा संभव होता है:

let x = (x.do_something() await).do_another_thing() await;
let x = x.foo(|| ...).bar(|| ... ).baz() 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 के लिए ले जाया गया प्रतीत होता है https://github.com/rust-lang/rust/issues/53548।

Async-प्रतीक्षित स्थिति रिपोर्ट:

http://smallcultfollowing.com/babysteps/blog/2019/03/01/async-await-status-report/

मैं async-प्रतीक्षा की स्थिति पर एक त्वरित अद्यतन पोस्ट करना चाहता था
प्रयास। संक्षिप्त संस्करण यह है कि हम घरेलू खिंचाव में हैं
किसी प्रकार का स्थिरीकरण, लेकिन कुछ महत्वपूर्ण हैं
काबू पाने के लिए सवाल।

कार्यान्वयन कार्य समूह की घोषणा

इस पुश के हिस्से के रूप में, मुझे यह घोषणा करते हुए खुशी हो रही है कि हमने एक का गठन किया है
async-प्रतीक्षा कार्यान्वयन कार्य समूह । यह कार्य समूह
संपूर्ण async-प्रतीक्षित प्रयास का हिस्सा है, लेकिन पर केंद्रित है
कार्यान्वयन, और संकलक टीम का हिस्सा है। यदि आप करना चाहते हैं
फिनिश लाइन पर async-प्रतीक्षा प्राप्त करने में सहायता करें, हमारे पास मुद्दों की एक सूची है
जहां हम निश्चित रूप से मदद चाहते हैं (पढ़ें)।

यदि आप भाग लेने में रुचि रखते हैं, तो हमारे पास "कार्यालय समय" हैमंगलवार के लिए निर्धारित ([संकलक टीम कैलेंडर देखें]) -- यदि आप
फिर [ज़ूलिप] पर दिखाई दे सकता है, यह आदर्श होगा! (लेकिन यदि नहीं, तो बस किसी में पॉप करें
समय।)

...

https://github.com/rust-lang/rust/issues/59001

std::future::Future कब स्थिर रहेगा? क्या इसे async प्रतीक्षा के लिए प्रतीक्षा करनी होगी? मुझे लगता है कि यह एक बहुत अच्छा डिज़ाइन है और मैं इसमें कोड पोर्ट करना शुरू करना चाहता हूं। (क्या इसे स्थिर में उपयोग करने के लिए कोई शिम है?)

@ इसके लिए ताज़ा ट्रैकिंग समस्या देखें :

async/प्रतीक्षा के लिए एक और संकलक समस्या: https://github.com/rust-lang/rust/issues/59245

यह भी ध्यान दें कि शीर्ष पोस्ट में https://github.com/rust-lang-nursery/futures-rs/issues/1199 को चेक किया जा सकता है, क्योंकि यह अब ठीक हो गया है।

ऐसा लगता है कि HRLB और async के बंद होने में कोई समस्या है: https://github.com/rust-lang/rust/issues/59337। (हालांकि, आरएफसी को फिर से स्किम करना यह वास्तव में निर्दिष्ट नहीं करता है कि एसिंक क्लोजर उसी तर्क के अधीन हैं जो एसिंक फ़ंक्शन के जीवनकाल कैप्चर करता है)।

हाँ, एसिंक्स क्लोजर में मुद्दों का एक समूह है और इसे स्थिरीकरण के प्रारंभिक दौर में शामिल नहीं किया जाना चाहिए। वर्तमान व्यवहार को क्लोजर + एसिंक ब्लॉक के साथ अनुकरण किया जा सकता है, और भविष्य में मुझे एक ऐसा संस्करण देखना अच्छा लगेगा जो क्लोजर के अपवर को लौटाए गए भविष्य से संदर्भित करने की अनुमति देता है।

मैंने अभी देखा है कि वर्तमान में await!(fut) आवश्यक है कि fut Unpin : https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist= 9c189fae3cfeecbb041f68f02f31893d

क्या यह अपेक्षित है? यह आरएफसी में प्रतीत नहीं होता है।

@Ekleog जो await! त्रुटि नहीं दे रहा है, await! अवधारणात्मक रूप से पारित भविष्य को स्टैक-पिन करता है ताकि !Unpin फ्यूचर्स का उपयोग किया जा सके ( त्वरित खेल का मैदान उदाहरण )। त्रुटि impl Future for Box<impl Future + Unpin> पर बाधा से आती है, जिसके लिए आपको कुछ ऐसा करने से रोकने के लिए भविष्य 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 और इससे मूल्य को स्थानांतरित करने की अनुमति देता है जिससे आप भविष्य को एक ही ढेर स्थान में एक बार मतदान कर सकते हैं, फिर भविष्य को बॉक्स से बाहर ले जाएं और इसे एक नए ढेर स्थान और मतदान में डाल दें वह फिर से।

प्रतीक्षा को संभवतः Box<dyn Future> अनुमति देने के लिए विशेष आवरण होना चाहिए क्योंकि यह भविष्य का उपभोग करता है

शायद IntoFuture विशेषता को await! लिए पुनर्जीवित किया जाना चाहिए? Box<dyn Future> इसे Pin<Box<dyn Future>> परिवर्तित करके कार्यान्वित कर सकता है।

एसिंक/प्रतीक्षा के साथ मेरा अगला बग यहां आता है: ऐसा लगता है कि एक async fn ब्रेक अनुमान के रिटर्न प्रकार में एक प्रकार के पैरामीटर के लिए एक संबद्ध प्रकार का उपयोग करना: https://github.com/rust-lang/rust/ मुद्दे/60414

शीर्ष-पोस्ट की सूची में संभावित रूप से # 60414 जोड़ने के अलावा (पता नहीं है कि यह अभी भी उपयोग किया जा रहा है - शायद यह जीथब लेबल को इंगित करना बेहतर होगा?), मुझे लगता है कि "जंग-लैंग का समाधान/ rfcs#2418” पर निशान लगाया जा सकता है, क्योंकि IIRC के Future विशेषता को हाल ही में स्थिर किया गया है।

मैं अभी एक रेडिट पोस्ट से आया हूं और मुझे कहना होगा कि मुझे पोस्टफिक्स सिंटैक्स बिल्कुल पसंद नहीं है। और ऐसा लगता है कि अधिकांश रेडिट इसे पसंद नहीं करते हैं।

मैं बल्कि लिखता हूँ

let x = (await future)?

उस अजीब वाक्य रचना को स्वीकार करने से।

चेनिंग के लिए, मैं 1 await से अधिक होने से बचने के लिए अपने कोड को दोबारा कर सकता हूं।

साथ ही, भविष्य में जावास्क्रिप्ट ऐसा कर सकता है ( स्मार्ट पाइपलाइन प्रस्ताव ):

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- में व्यापक रूप से चर्चा की गई है।

कृपया यहाँ डिज़ाइन निर्णयों पर चर्चा न करें, इस स्पष्ट उद्देश्य के लिए एक सूत्र है

यदि आप वहां टिप्पणी करने की योजना बना रहे हैं, तो कृपया ध्यान रखें कि चर्चा पहले ही काफी हो चुकी है: सुनिश्चित करें कि आपके पास कहने के लिए कुछ महत्वपूर्ण है, और सुनिश्चित करें कि इसे पहले सूत्र में नहीं कहा गया है।

@ मेरी समझ के लिए

क्या 4 जुलाई को अगले बीटा कट के लिए समय पर स्थिर होने का इरादा है, या बग को रोकने के लिए एक और चक्र को हल करने की आवश्यकता होगी? A-async-प्रतीक्षा टैग के अंतर्गत बहुत सारे खुले मुद्दे हैं, हालांकि मुझे यकीन नहीं है कि उनमें से कितने महत्वपूर्ण हैं।

आह, इस पर ध्यान न दें, मैंने अभी - अभी खोजा है ।

नमस्ते! हमें इस सुविधा के स्थिर रिलीज की उम्मीद कब करनी है? और मैं इसे रात के निर्माण में कैसे उपयोग कर सकता हूं?

@MehrdadKhnzd https://github.com/rust-lang/rust/issues/62149 में लक्ष्य रिलीज की तारीख और अधिक के बारे में जानकारी है

वहाँ योजना अपने आप को लागू करने की है Unpin वायदा है कि द्वारा उत्पन्न कर रहे के लिए async fn ?

विशेष रूप से मैं सोच रहा हूं कि क्या भविष्य में उत्पन्न कोड के कारण अनपिन स्वचालित रूप से उपलब्ध नहीं है, या क्या हम संदर्भों को तर्क के रूप में उपयोग कर सकते हैं

@DoumanAsh मुझे लगता है कि अगर async fn के पास उपज बिंदुओं पर कभी भी कोई सक्रिय आत्म-संदर्भ नहीं होता है, तो उत्पन्न भविष्य संभवतः अनपिन को लागू कर सकता है, हो सकता है?

मुझे लगता है कि कुछ बहुत उपयोगी त्रुटि संदेशों के साथ "इस_ उधार के कारण Unpin नहीं" कहने की आवश्यकता होगी + "वैकल्पिक रूप से आप इस भविष्य को बॉक्स कर सकते हैं" का एक संकेत

#63209 पर स्थिरीकरण पीआर नोट करता है कि "सभी अवरोधक अब बंद हो गए हैं।" और 20 अगस्त को रात में उतरा था, इसलिए इस सप्ताह के अंत में बीटा कट के लिए जा रहा था। यह ध्यान देने योग्य लगता है कि 20 अगस्त से कुछ नए अवरोधन मुद्दे दर्ज किए गए हैं (जैसा कि AsyncAwait-Blocking टैग द्वारा ट्रैक किया गया है)। इनमें से दो (#63710, #64130) अच्छे-से-अच्छे प्रतीत होते हैं जो वास्तव में स्थिरीकरण में बाधा नहीं डालेंगे, हालांकि तीन अन्य मुद्दे हैं (#64391, #64433, #64477) जो चर्चा के लायक प्रतीत होते हैं। ये बाद के तीन मुद्दे संबंधित हैं, ये सभी पीआर #64292 के कारण उत्पन्न हुए हैं, जो स्वयं AsyncAwait-Blocking समस्या # 63832 को संबोधित करने के लिए उतरा था। एक पीआर, #64584, पहले ही बड़ी संख्या में समस्याओं को हल करने के प्रयास में उतर चुका है, लेकिन तीन मुद्दे अभी के लिए खुले हैं।

सिल्वर लाइनिंग यह है कि तीन गंभीर ओपन ब्लॉकर्स चिंता कोड के लिए प्रतीत होते हैं जिन्हें संकलित करना चाहिए , लेकिन वर्तमान में संकलित नहीं होता है। उस अर्थ में, यह बैकवर्ड-संगत होगा, बाद में बीटा-आइज़ेशन और एसिंक/प्रतीक्षा के अंतिम स्थिरीकरण को बाधित किए बिना लैंड फिक्स के लिए। हालांकि, मैं सोच रहा हूँ लैंग टीम से किसी को भी सोचता है कि क्या है कि कुछ भी यहाँ सुझाव देने के लिए पर्याप्त के विषय में है कि async / इंतजार एक और चक्र (जो, अरुचिकर है कि लग सकता है के रूप में के रूप में, तेजी से रिलीज के कार्यक्रम की बात है के लिए हर रात को पर बेक चाहिए आख़िरकार)।

@bstree हम उन्हें "उच्च प्राथमिकता" के रूप में नोट करने के लिए बेहतर लेबल की कमी के लिए "AsyncAwait-blocking" का पुन: उपयोग कर रहे हैं, वे वास्तव में अवरुद्ध नहीं कर रहे हैं। हमें लेबलिंग प्रणाली को जल्द ही सुधारना चाहिए ताकि इसे कम भ्रमित करने वाला बनाया जा सके, cc @nikomatsakis.

... अच्छा नहीं... हम 1.38 की अपेक्षा में async-प्रतीक्षा से चूक गए। 1.39 के लिए इंतजार करना पड़ रहा है, सिर्फ इसलिए कि कुछ "मुद्दों" की गिनती नहीं हुई ...

@earthengine मुझे नहीं लगता कि यह स्थिति का उचित आकलन है। जो मुद्दे सामने आए हैं, वे सभी गंभीरता से लेने लायक हैं। लोगों के लिए केवल async प्रतीक्षा करना अच्छा नहीं होगा, फिर इन मुद्दों में इसे अभ्यास में उपयोग करने की कोशिश कर रहे हैं :)