220 11312 article Path: news.gmane.org!not-for-mail From: Jeremy Maitin-Shepard Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Comments on n3976 (array_view) Date: Fri, 13 Jun 2014 20:34:18 -0700 (PDT) Lines: 107 Approved: news@gmane.org Message-ID: References: <7177de96-50e1-4590-99dc-eda255203f26@isocpp.org> <5ff6c439-3147-4d5f-809a-8adf86c17dc4@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_369_5498767.1402716858172" X-Trace: ger.gmane.org 1402716872 31956 80.91.229.3 (14 Jun 2014 03:34:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Jun 2014 03:34:32 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCYZZ4E5WQCRBO4F56OAKGQEYVCWFDI@isocpp.org Sat Jun 14 05:34:22 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f197.google.com ([209.85.223.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WvejV-0008J1-GQ for gclcip-std-proposals@m.gmane.org; Sat, 14 Jun 2014 05:34:21 +0200 Original-Received: by mail-ie0-f197.google.com with SMTP id lx4sf18251065iec.8 for ; Fri, 13 Jun 2014 20:34:20 -0700 (PDT) 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:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=qMTtWqpM7hGzfI5nQxXmtZBDUtM9ye5Xg87yP5sXeIM=; b=J8WDDq6HHOSKLFlSc1IKcHURTEUA3Q4V4PYctLExPcRIrOnMpAnp5da1YHfSjTesGD wP25PyLd57CnFmjrWNcr3ILho+L3bnuEBhN2EzsbmzGpI8nHK4JIgufF0CWjULYGUhmZ lqIu9Bq0uoAuY3KRzqs9tRJmf5XWT/EUdTRT9i8xExELoJnay0zy4KSlxtY/lIpyaRrF msW+QzimEsYbZqvSUV9vQ2c0SRwisEGxbH5vhO9ep0s5x+EK/QgvOHs1P6B65ernvhCy vGQTjW/G4ZLt3/sr9EJ5Syez6pRCSAPlUTYQ7zgAdfH62AdUulT260y2JNFSbqsnFWVH d6+A== X-Gm-Message-State: ALoCoQmJazW9iA9RSX7jKjRkZLRhEp7We971spXW3qDN6TTN0LkqTOI7kv5ANwZEcggPHb2BFUTV X-Received: by 10.182.249.115 with SMTP id yt19mr2094209obc.25.1402716860402; Fri, 13 Jun 2014 20:34:20 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.7.39 with SMTP id g7ls52705iga.12.canary; Fri, 13 Jun 2014 20:34:19 -0700 (PDT) X-Received: by 10.50.111.16 with SMTP id ie16mr166364igb.14.1402716859555; Fri, 13 Jun 2014 20:34:19 -0700 (PDT) In-Reply-To: X-Original-Sender: jeremy@jeremyms.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:11312 Archived-At: ------=_Part_369_5498767.1402716858172 Content-Type: text/plain; charset=UTF-8 On Friday, June 13, 2014 4:56:47 PM UTC-7, Sean Middleditch wrote: > > Adding a bunch of cruft that is planned to be obsoleted with an update > right around the corner seems like a waste of time and needless bloat > to the library for no practical gain. It's not even clear that there's > any point in time we'd even need the interim solution: C++14 is done, > no new library additions are going to be made to it, all work going > forward is for C++17, and it's rather likely that the first version of > comprehensive ranges will either be in C++17 or a TS released around > the same time. > You may be right, that it would be redundant with some range-related facility, and any array_view proposal should probably be seen as tentative pending the results of the range group. However, it is clear that a one-dimensional array view is a facility that should exist, under some name, in the standard library. The only real questions are: 1. should it be represented as (begin,size) or (begin,end) [doesn't really matter, and possibly could be implementation-defined even] 2. what to call it 3. what methods/functions should be defined for it Note also that it benefits from implicit conversions from types like std::array, std::vector, std::string, etc. It is also clear that we need an iterator_range type similar to boost::iterator_range, regardless of what alternate range models may also exist. (However, it could be useful to allow the begin and end iterators to optionally have different types.) Therefore, we can be fairly certain that any range library proposal will include an iterator_range type, and iterator_range would *almost* make a one-dimensional array_view redundant. The reason I say almost is that iterator_range might well not be implicitly constructible from std::vector and std::string, for instance, if their iterators are not pointers. It would be possible to allow that as a special case for iterator_range, but then we are effectively just defining array_view but giving it the name iterator_range. -- --- 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_369_5498767.1402716858172 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Friday, June 13, 2014 4:56:47 PM UTC-7, Sean Mi= ddleditch wrote:
Adding a bunch= of cruft that is planned to be obsoleted with an update
right around the corner seems like a waste of time and needless bloat
to the library for no practical gain. It's not even clear that there's
any point in time we'd even need the interim solution: C++14 is done,
no new library additions are going to be made to it, all work going
forward is for C++17, and it's rather likely that the first version of
comprehensive ranges will either be in C++17 or a TS released around
the same time.

You may be right, that it would be redundant with= some range-related facility, and any array_view proposal should probably b= e seen as tentative pending the results of the range group.  However, = it is clear that a one-dimensional array view is a facility that should exi= st, under some name, in the standard library.  The only real questions= are:
1. should it be represented as (begin,size) or (begin,end) [doesn'= t really matter, and possibly could be implementation-defined even]
2. w= hat to call it
3. what methods/functions should be defined for it
Note also that it benefits from implicit conversions from types like std::= array, std::vector, std::string, etc.

It is also clear that we need = an iterator_range type similar to boost::iterator_range, regardless of what= alternate range models may also exist.  (However, it could be useful = to allow the begin and end iterators to optionally have different types.)&n= bsp; Therefore, we can be fairly certain that any range library proposal wi= ll include an iterator_range type, and iterator_range<pointer> would = *almost* make a one-dimensional array_view redundant.  The reason I sa= y almost is that iterator_range<T *> might well not be implicitly con= structible from std::vector and std::string, for instance, if their iterato= rs are not pointers.  It would be possible to allow that as a special = case for iterator_range<T *>, but then we are effectively just defini= ng array_view<T> but giving it the name iterator_range<T *>.

--

---
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_369_5498767.1402716858172-- .