220 21504 <72ae6d7c-28ad-445a-9e5e-f3e7a6de31e5@isocpp.org> article Path: news.gmane.org!not-for-mail From: Gor Nishanov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Resumable expressions p0114r0 vs async/await P0057R0 Date: Sat, 10 Oct 2015 07:58:13 -0700 (PDT) Lines: 200 Approved: news@gmane.org Message-ID: <72ae6d7c-28ad-445a-9e5e-f3e7a6de31e5@isocpp.org> References: <639f0012-8cb4-4db3-82a6-8d042a3497f9@isocpp.org> <643e2b46-3636-41e9-881b-b1d9cb1d0a7f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4097_1640121953.1444489093194" X-Trace: ger.gmane.org 1444489210 5393 80.91.229.3 (10 Oct 2015 15:00:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Oct 2015 15:00:10 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC47RF4IW4GRBZOP4SYAKGQEER3EGRI@isocpp.org Sat Oct 10 16:59:55 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f199.google.com ([209.85.192.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zkvcl-00059G-Ix for gclcip-std-proposals@m.gmane.org; Sat, 10 Oct 2015 16:59:51 +0200 Original-Received: by pdpu3 with SMTP id u3sf38888455pdp.1 for ; Sat, 10 Oct 2015 07:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=oS9RoQIP4ToUPiffdaIDNDEGVhZTl9Shi+tqZjaxV8M=; b=jIJI/7JEVmecSwwcdASUgojVi6CN5E+kPUpuPgqlk/oMG9Y3bH7oVL/CPadBgaxaRn aPjsKLI3K/CG1CMJuvpIWK1LllftpNJQgMLmlEt13V3sJ0hCJB4PD+E7sZXM6DnzKTOC d6+SCE6x24/RISbAIyriuCJ4cKG7FH3Oit0TWZ5W9rUhWbJ2zTKybiilQu/vyggW4hDJ vb6JMisjS/LTJXmC9K40+AOr9jkU67mX81a8TyWUakuJaoz/+sfijg1Ph00i2uZzOdnz vs1loUqLaDyBWi/VqrWm6odzbQ237aHYEw3lD1iRHyS/T5rAvbf0+lTwU//FB0WxktaU G2LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=oS9RoQIP4ToUPiffdaIDNDEGVhZTl9Shi+tqZjaxV8M=; b=B23U+OcccHMOx/sx47EK8j2COXBx967z1Cfija0W5a6B2IryBM6UwFFpxFL/Vf4rkN n8QExU/WMCnluzybDgaOfed7y0wdBcTXB1hR90XExWvQS3MkC4w6GdqmuqO8N3NY6t/G 34SbhkEXW58hquZnit8r469ZEUGXhhf86lUCKBaDz8nHjAgnu5heiZg1IZ8g64bSTtdV uvX0eJRLjIs6nQWb89DILjC5dGwlwifaQ4OTO1ixSP38MOYUaxWphgRnA2YtorVprn+S FiPeO6Onu8Gagn7ZpQSWXML8xQC6rYJIWkxyuYnQ99660swjkoapB2xLVsBeObHaZryb AJUg== X-Gm-Message-State: ALoCoQnlaGhb2RsbFNRd6754QUmxLweB6WbhTrjTDEhPrZWA6Zt1KYFOwpgeSJ4DTVVwuL7dJtFD X-Received: by 10.66.62.228 with SMTP id b4mr15456046pas.10.1444489189749; Sat, 10 Oct 2015 07:59:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.135.25 with SMTP id j25ls1130150iod.14.gmail; Sat, 10 Oct 2015 07:59:48 -0700 (PDT) X-Received: by 10.50.112.4 with SMTP id im4mr59349igb.1.1444489093766; Sat, 10 Oct 2015 07:58:13 -0700 (PDT) In-Reply-To: <643e2b46-3636-41e9-881b-b1d9cb1d0a7f@isocpp.org> X-Original-Sender: GorNishanov@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:21504 Archived-At: ------=_Part_4097_1640121953.1444489093194 Content-Type: multipart/alternative; boundary="----=_Part_4098_29049363.1444489093204" ------=_Part_4098_29049363.1444489093204 Content-Type: text/plain; charset=UTF-8 On Saturday, October 10, 2015 at 7:22:40 AM UTC-7, Nicol Bolas wrote: > > On the recent `operator await` syntax in P0057. Is it possible for a user > to call this operator these themselves? And if so, will it work correctly > for types that don't provide one (that is, resolving to the original type > or issuing a compiler error)? > > If not, it would probably be useful if the user could invoke it themselves. > Absolutely, observe me doing this in the main of the attached program: int main() { operator await(1ms); One thing that is somewhat awkward: operator await(1ms); is not the same as await 1ms; The first one, gets me an awaitable from 1ms. Another is await-ing 1ms. Difference between calling an operator function directly or calling it via operator notation, is not exactly novel. The behavior of (x || y) is different from calling operator||(x,y). I don't like it much. I don't mind operator await to be renamed to get_awaiter or something, but, I do think that operator await is prettier and it is easier to think that language synthesizes operator await for some types rather than synthesizing a function. Again, I am slightly leaning toward operator await, rather than get_awaiter, but if Core/Evolution/LWG/LEWG wants something else. Absolutely. -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_4098_29049363.1444489093204 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Saturday, October 10, 2015 at 7:22:40 AM UTC-7,= Nicol Bolas wrote:
On the rec= ent `operator await` syntax in P0057. Is it possible for a user to call thi= s operator these themselves? And if so, will it work correctly for types th= at don't provide one (that is, resolving to the original type or issuin= g a compiler error)?

If not, it would probably be useful if the user= could invoke it themselves.

Abso= lutely, observe me doing this in the main of the attached program:

int main() {

=

=C2=A0=C2=A0 operator= await(1ms);

One thing that is somewhat awkward:

=C2=A0=C2=A0 operator = await(1ms);

is not the same as

=C2=A0=C2= =A0=C2=A0await 1ms;

The first one, gets me an awaitable from 1ms. Another is= await-ing=C2=A01ms.
Di= fference between calling an operator function directly or calling it via op= erator notation, is not exactly novel.
The behavior of (x || y) is diff= erent from calling operator||(x,y).
I don't like it much. I don't mind operator await to b= e renamed to get_awaiter or something, but, I do think that operator await = is prettier and it is easier to think that language synthesizes operator aw= ait for some types rather than synthesizing a function.

Again, I am slightly leaning toward operator await, rather t= han get_awaiter, but if Core/Evolution/LWG/LEWG wants something else. Absol= utely.

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_4098_29049363.1444489093204-- ------=_Part_4097_1640121953.1444489093194 Content-Type: text/x-c++src; charset=US-ASCII; name=opawait.cpp Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=opawait.cpp X-Attachment-Id: 2da6fbc0-f5be-4f2f-bbb0-dd1a7069ddbf Content-ID: <2da6fbc0-f5be-4f2f-bbb0-dd1a7069ddbf> #include #include #include #include #include #include #include using namespace std::chrono; class awaiter { static void CALLBACK TimerCallback(PTP_CALLBACK_INSTANCE, void *Context, PTP_TIMER) { std::experimental::coroutine_handle<>::from_address(Context)(); } PTP_TIMER timer = nullptr; std::chrono::system_clock::duration duration; public: explicit awaiter(std::chrono::system_clock::duration d) : duration(d) {} bool await_ready() const { return duration.count() <= 0; } bool await_suspend(std::experimental::coroutine_handle<> resume_cb) { int64_t relative_count = -duration.count(); timer = CreateThreadpoolTimer(TimerCallback, resume_cb.to_address(), nullptr); SetThreadpoolTimer(timer, (PFILETIME)&relative_count, 0, 0); return timer != 0; } void await_resume() {} ~awaiter() { if (timer) CloseThreadpoolTimer(timer); } }; auto sleep_for(std::chrono::system_clock::duration duration) { return awaiter{duration}; } auto operator await(std::chrono::system_clock::duration duration) { return awaiter{duration}; } SRWLOCK lock = {SRWLOCK_INIT}; struct coro { struct promise_type { auto get_return_object() { return coro{}; } bool initial_suspend() { return false; } bool final_suspend() { return false; } void return_void() {} }; }; coro test() { puts("sleeping..."); await sleep_for(1ms); puts(" woke up ... going to sleep again..."); await 1ms; puts(" ok. you woke me up againt. I am out of here\n"); ReleaseSRWLockExclusive(&lock); } int main() { operator await(1ms); AcquireSRWLockExclusive(&lock); test(); AcquireSRWLockExclusive(&lock); } ------=_Part_4097_1640121953.1444489093194-- .