220 5262 <7d4f5cb3-1409-4c74-a7da-c5b92f6dd011@isocpp.org> article Path: news.gmane.org!not-for-mail From: asaelr@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Some thoughts about coroutines Date: Thu, 27 Jun 2013 10:04:43 -0700 (PDT) Lines: 83 Approved: news@gmane.org Message-ID: <7d4f5cb3-1409-4c74-a7da-c5b92f6dd011@isocpp.org> References: <291db835-d42d-40cd-8760-47cdf327680d@isocpp.org> <7d8a2d85-0995-4833-ad0c-75577f293b63@isocpp.org> <2c77506f-433f-43b7-871f-e429c4b295bf@isocpp.org> <3e94ef89-4ea8-4549-827f-94dd7a32b9fa@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_272_26375908.1372352683246" X-Trace: ger.gmane.org 1372352687 10199 80.91.229.3 (27 Jun 2013 17:04:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Jun 2013 17:04:47 +0000 (UTC) Cc: asaelr@gmail.com, asaelr@gmail.com, asaelr@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCB23LHRZUKRBK7BWGHAKGQEKRYEGZI@isocpp.org Thu Jun 27 19:04:46 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-gh0-f199.google.com ([209.85.160.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UsFcj-0008D9-3r for gclcip-std-proposals@m.gmane.org; Thu, 27 Jun 2013 19:04:45 +0200 Original-Received: by mail-gh0-f199.google.com with SMTP id g14sf1250147ghb.6 for ; Thu, 27 Jun 2013 10:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:date:from:to:cc:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-google-group-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe:content-type; bh=kLCae2f/wkETCJtLpGm2XCX6pGgUUyRfpjQ3a/X5T0U=; b=FFyWKMkhlHYDNkji6kfCcE2hgfLovp/fRh6945fG97ijda4SHUGopyua7DdaHETsAl Am5vM6PELF7lwHd5p4aEax0mlhFjp+Rrfht7CErMkEj9AvS3G23eO3kJhUWagz4XET1L QH3xzUkq7e6ssojqrVS6rLgUFTRGOB9cMoEj4LrvGIJ9rcB4S0i7AD+LDwZOYzmdI3bu qwp4KvWyjDah5ZKE1w+MRF6PEF4Db+BX2Fwg0BeQ5g1uwkxDJHU8UUm26PeSEUgzmjG5 BcRpKdhb6bBbnlfIw6DTkREtbfSpXOzgtNFLyHhgykOJmVGYbkr7VgVUhsymTo1Jv9Nq yhnw== X-Received: by 10.224.86.200 with SMTP id t8mr9593680qal.0.1372352684276; Thu, 27 Jun 2013 10:04:44 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.83.134 with SMTP id q6ls869463qey.89.gmail; Thu, 27 Jun 2013 10:04:43 -0700 (PDT) X-Received: by 10.49.24.208 with SMTP id w16mr269229qef.37.1372352683635; Thu, 27 Jun 2013 10:04:43 -0700 (PDT) In-Reply-To: <3e94ef89-4ea8-4549-827f-94dd7a32b9fa@isocpp.org> X-Original-Sender: asaelr@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:5262 Archived-At: ------=_Part_272_26375908.1372352683246 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think I'm starting to realize the confusing. You mean that operator*=20 should do both the increment and the access. I meant that operator* will do= =20 the access, and operator++ will do the incrementing (you can see the=20 implementation in my first message). Incrementing output iterators doesn't make sense, but incrementing a=20 coroutine make. (In *fib* example, it means "yield the next Fibonacci=20 number"). I think that the common concept of iterators is to separate incrementing=20 and accessing, so *for* loops (and, specially, for range loops) can=20 increment, check if we done, and only then access. =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=97=D7=9E=D7=99= =D7=A9=D7=99, 27 =D7=91=D7=99=D7=95=D7=A0=D7=99 2013 19:01:26 UTC+3, =D7=9E= =D7=90=D7=AA Xeo: > > Why should it be no-op? What happens if I call *++it* again?=20 >> > Nothing. Why should anything happen? Currently, output iterators'=20 > `operator++` is also no-op, since the concept of "incrementing" doesn't= =20 > make sense for them.=20 > --=20 ---=20 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 e= mail 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-proposa= ls/. ------=_Part_272_26375908.1372352683246 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think I'm starting to realize the confusing. You mean that operator* shou= ld do both the increment and the access. I meant that operator* will do the= access, and operator++ will do the incrementing (you can see the implement= ation in my first message).

Incrementing output iterators doesn't ma= ke sense, but incrementing a coroutine make. (In fib example, it mea= ns "yield the next Fibonacci number").
I think that the common concept o= f iterators is to separate incrementing and accessing, so for loops = (and, specially, for range loops) can increment, check if we done, and only= then access.

=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7= =9D =D7=97=D7=9E=D7=99=D7=A9=D7=99, 27 =D7=91=D7=99=D7=95=D7=A0=D7=99 2013 = 19:01:26 UTC+3, =D7=9E=D7=90=D7=AA Xeo:
Why should it be no-op? Wh= at happens if I call ++it again?
Nothing. Why = should anything happen? Currently, output iterators' `operator++` is also n= o-op, since the concept of "incrementing" doesn't make sense for them.
=

--
 
---
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-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/<= /a>.
 
 
------=_Part_272_26375908.1372352683246-- .