220 39240 <904aab35-44dd-4053-91d9-c02cbd4051a0@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Standardising a type-erased iterator Date: Fri, 20 Jul 2018 06:26:59 -0700 (PDT) Lines: 160 Approved: news@gmane.org Message-ID: <904aab35-44dd-4053-91d9-c02cbd4051a0@isocpp.org> References: <09db196a-e818-4d7a-9af1-48f07b2f4c3d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5318_1243352391.1532093219598" X-Trace: blaine.gmane.org 1532093095 13472 195.159.176.226 (20 Jul 2018 13:24:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 20 Jul 2018 13:24:55 +0000 (UTC) Cc: florian.csdt@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBJGGY7NAKGQEFJINMDQ@isocpp.org Fri Jul 20 15:24:51 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f198.google.com ([209.85.161.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fgVOs-0003Pb-FH for gclcip-std-proposals@m.gmane.org; Fri, 20 Jul 2018 15:24:50 +0200 Original-Received: by mail-yw0-f198.google.com with SMTP id p8-v6sf6324726ywl.14 for ; Fri, 20 Jul 2018 06:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=H8mdyqM/EVsbrJrDN9Y8+Rc4IzscRGjPaavP2PYeFqs=; b=vjVN2lE0FQNijnIQVYjtLdly7rzKBxCMV4ST81XAahhsB1nSS/byjnAhGF1RswerBT p3M6W0PUbrIN+E8GTmuR6tE+UDEXhd3HBR124ya8XA9jKGIB2ajR+LGE+6uCKTsHwHgc aPQmuPL1ncZdQ5oFgVn3AC7tfrsT+3zjugQxX4keBt1H3ixq+MojL7mzIVkrIaK0lQ7m fpbb8+bFOkJb3M8rDnvlh3cj5hqkF1c03zBDcKaS3Cvo3W5QSHUIMNPG8ax0MUGjXIK0 g5CnxlmsQbOtYHsdMQkXB2CBZd08slzbchFC2pGaZGUOM/SQ3QYvrcWFq9INE95KARVJ 7ykw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=H8mdyqM/EVsbrJrDN9Y8+Rc4IzscRGjPaavP2PYeFqs=; b=LOVfdKQKtD6ouGOfkHAnM86422YELqLSUG1dIPQ3oOvymozAeKOzmbXRsHTU7T2+4c rCLEEhA3tq8BVB5wYGSqR4nvEa41yxUcaIQksXwmM53POtXIGsCtogVDkp2i4tm2crbI f7iBxA10VrgVzw52ZhoZjv1NKerTN8tQl68z51fzo5vMHJV0gyoiCuca5f6C+xEDzcKV V+0+tgybiIsFqi8ssKHxRTDvpAy7RS10GjCRUD2gcfVLfUeoMJU9p9Sr47HB+0kbgxlJ H0Xjf3r85w7emYu6ScfEh4tnsKATeo1+awjgQqNeewSU0viyV/XtAs8Zpxab/FJDDPQJ cyyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version: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=H8mdyqM/EVsbrJrDN9Y8+Rc4IzscRGjPaavP2PYeFqs=; b=DFNdn7fvY0pSCKQSpWk8fAQNqX4ZSg8PRgF/3wPMitt2P1VEAuhBmKIG2dIZ7hUVpq xFP4tEI/+d/pfGMYp0ptoEzzhcW/EQ6MCcuV6hmTbH3YvZGshJQckZdDyo9nPw5Wl26l hdYFWjOMnPV16qcTaOJWn6OlLsDkzXEJSmLTqI8BuWTLnmwxKvVYbgm/Q9kgBMKlyFv8 ez+Ju4D7bRwFo8oexEX8lMjlHtplz0OlEFtX+x6dQtTUprHWDiLVICaBawAc5Wt1CMMr 9lDhBo8WTWXsdOJNH90DubU7hv/u+vOSopnFdCMtbgCDCCQ7bm6pJo61aFjP+Ik00X4R uGMA== X-Gm-Message-State: AOUpUlGqAGyJpKFHpzk031J4Wa76MJAAzfg2YQnwmCoPil3AxJwrJfF/ aSrPEq8VfLiVxQ80uQzr6YPJVA== X-Google-Smtp-Source: AAOMgpdC67Xo4UXNDT9U16rcc1VDX5ny8Kqo7HiX9UwaZFTnXGzRGYxRRH/tdjA/Ix+uEWiHnIKUpA== X-Received: by 2002:a0d:e486:: with SMTP id n128-v6mr521489ywe.217.1532093221211; Fri, 20 Jul 2018 06:27:01 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:814e:: with SMTP id j14-v6ls438814ybm.3.gmail; Fri, 20 Jul 2018 06:27:00 -0700 (PDT) X-Received: by 2002:a25:8486:: with SMTP id v6-v6mr61616ybk.3.1532093220028; Fri, 20 Jul 2018 06:27:00 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:39240 Archived-At: ------=_Part_5318_1243352391.1532093219598 Content-Type: multipart/alternative; boundary="----=_Part_5319_1618973395.1532093219598" ------=_Part_5319_1618973395.1532093219598 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Friday, July 20, 2018 at 5:17:54 AM UTC-4, floria...@gmail.com wrote: > > Le vendredi 20 juillet 2018 11:04:52 UTC+2, Thomas Russell a =C3=A9crit : >> >> Hi all, >> >> I've written a proposal document and sample implementation for an=20 >> `any_iterator` class template to add to the standard library, and was=20 >> hoping for some feedback before I look for a paper number.=20 >> >> This is a type-erased class which corresponds to the C++ named=20 >> requirements for the various iterator classes (OutputIterator,=20 >> ForwardIterator, etc.). >> >> This will allow developers to take advantage of physical design=20 >> methodology to improve compile time and reduce dependencies between=20 >> components, whilst still writing generic code only depending on the=20 >> requirements that they care about. >> >> It it is in a similar space to `std::function` in that it owns the=20 >> underlying object and models a C++ named requirement (Callable for=20 >> `std::function` and the iterator requirements for `std::any_iterator`). >> >> The sample implementation and proposal can be found in this repository:= =20 >> https://github.com/Shaktal/any_iterator >> >> Many thanks,=20 >> Thomas=20 >> > > I don't know if it would be fast enough for any real code, but that's=20 > interesting. > > I would also create a any_iterator_ref just to mimic std::function and=20 > std::function_ref proposal. That would allow to make it faster in the mos= t=20 > common cases: most of the time, I expect ownership will not be needed. > Actually, I think it's the opposite. You're far more likely to need=20 ownership of the iterator than of a function. Consider this: any_iterator it =3D vec.begin(); The iterator from `begin()` is a prvalue. So if `it` doesn't take ownership= =20 of it... nobody will. So now it's broken.=20 Because iterators are so frequently copied and passed around by value,=20 `any_iterator_ref` becomes quite dangerous. Also, iterators *have* to be SemiRegular types; that's a requirement from= =20 Ranges. So they're copyable. Coupled with the fact that most iterators will= =20 be small, it makes sense that `any_iterator` would just store a copy of=20 them. Lastly, if you're going to have `any_iterator`, you should also have=20 `any_range`, which is a range of `any_iterator`. And it might be a good=20 idea to investigate if you could provide sentinel support for=20 `any_iterator`, or if you can only do this through bounded ranges. --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/904aab35-44dd-4053-91d9-c02cbd4051a0%40isocpp.or= g. ------=_Part_5319_1618973395.1532093219598 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Friday, July 20, 2018 at 5:17:54 AM UTC-4, floria...@gm= ail.com wrote:
Le vendredi 20 juillet 2018 11:04:52 UTC+2, Thomas Russell a =C3=A9crit=C2= =A0:
Hi all,

I've written a pr= oposal document and sample implementation for an `any_iterator` class templ= ate to add to the standard library, and was hoping for some feedback before= I look for a paper number.

This is a type-erased class which corres= ponds to the C++ named requirements for the various iterator classes (Outpu= tIterator, ForwardIterator, etc.).

This will allow developers to take= advantage of physical design methodology to improve compile time and reduc= e dependencies between components, whilst still writing generic code only d= epending on the requirements that they care about.

It it is in a simi= lar space to `std::function` in that it owns the underlying object and mode= ls a C++ named requirement (Callable for `std::function` and the iterator r= equirements for `std::any_iterator`).

The sample implementation and p= roposal can be found in this repository: https://github.com/Shaktal/any_iterator

Many thanks,
= Thomas


I don't know if it would be= fast enough for any real code, but that's interesting.

<= /div>
I would also create a any_iterator_ref just to mimic std::functio= n and std::function_ref proposal. That would allow to make it faster in the= most common cases: most of the time, I expect ownership will not be needed= ..

Actually, I think it'= s the opposite. You're far more likely to need ownership of the iterato= r than of a function. Consider this:

any_iterator it =3D vec.begin();
The iterator from `begin()` is a prvalue. So if `it` doesn'= ;t take ownership of it... nobody will. So now it's broken.
Be= cause iterators are so frequently copied and passed around by value, `any_i= terator_ref` becomes quite dangerous.

=
Also, iterators have to be SemiRegular types; that's a requ= irement from Ranges. So they're copyable. Coupled with the fact that mo= st iterators will be small, it makes sense that `any_iterator` would just s= tore a copy of them.

Lastly, if you're going to hav= e `any_iterator`, you should also have `any_range`, which is a range of `an= y_iterator`. And it might be a good idea to investigate if you could provid= e sentinel support for `any_iterator`, or if you can only do this through b= ounded ranges.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/904aab35-44dd-4053-91d9-c02cbd4051a0= %40isocpp.org.
------=_Part_5319_1618973395.1532093219598-- ------=_Part_5318_1243352391.1532093219598-- .