220 11319 article Path: news.gmane.org!not-for-mail From: Sean Middleditch Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Comments on n3976 (array_view) Date: Sat, 14 Jun 2014 02:06:10 -0700 Lines: 67 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: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1402736780 20120 80.91.229.3 (14 Jun 2014 09:06:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Jun 2014 09:06:20 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCDODCNR2QPRBA5B6COAKGQE4SUJC2A@isocpp.org Sat Jun 14 11:06:13 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pb0-f71.google.com ([209.85.160.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wvjuf-00081m-2Y for gclcip-std-proposals@m.gmane.org; Sat, 14 Jun 2014 11:06:13 +0200 Original-Received: by mail-pb0-f71.google.com with SMTP id jt11sf13041598pbb.10 for ; Sat, 14 Jun 2014 02:06:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=ziQLrGIOQ5KVwcDPk3WcfPBe12/B7ZuOFg21i4APElc=; b=iQRoqQ+qzTDuRv+Oaljm4lqOoViwSXDaQ55OTFlFTpc12B+SHjiZn4v6MROo9VFVBB 2fOV7q/SVNQfWQ7d0tWYON/yY23ymLvkutIp73vaP0WdVWQrpEFgw6jQeBuOXHY/FDhh FNtQBWQ8BoY6lpXwAwAuPRzAIHUA9pbW9GtiK8idCbryWShEbJllL9kRlx/V1vNQLjln Z3MYFCtL624EtjwBr5RtnZE2lhJZJZFUor06IVHhiAit8AVWsciSn9F5cBjytxVam1pp jbMUSKGx/S27OUBmCxLyCZJ2Rv6EyfPwusCWf1wqkCxCp2ek1wli4omDoIWdA1GVc8Nh /txQ== X-Gm-Message-State: ALoCoQmtRJi1nIxqe09FZWl2iUHYX0He8dtqydZ4ft623QVEgUxOKrdBbqpnvQQjlJ7u4now/+A7 X-Received: by 10.66.65.202 with SMTP id z10mr2904989pas.45.1402736772022; Sat, 14 Jun 2014 02:06:12 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.92.68 with SMTP id a62ls1718309qge.79.gmail; Sat, 14 Jun 2014 02:06:11 -0700 (PDT) X-Received: by 10.52.6.227 with SMTP id e3mr5260184vda.10.1402736771163; Sat, 14 Jun 2014 02:06:11 -0700 (PDT) Original-Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [2607:f8b0:400c:c03::230]) by mx.google.com with ESMTPS id e7si2212047vey.73.2014.06.14.02.06.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Jun 2014 02:06:11 -0700 (PDT) Received-SPF: pass (google.com: domain of sean.middleditch@gmail.com designates 2607:f8b0:400c:c03::230 as permitted sender) client-ip=2607:f8b0:400c:c03::230; Original-Received: by mail-vc0-f176.google.com with SMTP id ik5so3205493vcb.35 for ; Sat, 14 Jun 2014 02:06:11 -0700 (PDT) X-Received: by 10.58.246.132 with SMTP id xw4mr6255767vec.2.1402736771021; Sat, 14 Jun 2014 02:06:11 -0700 (PDT) Original-Sender: sean.middleditch@gmail.com Original-Received: by 10.58.99.102 with HTTP; Sat, 14 Jun 2014 02:06:10 -0700 (PDT) In-Reply-To: X-Original-Sender: sean@middleditch.us X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of sean.middleditch@gmail.com designates 2607:f8b0:400c:c03::230 as permitted sender) smtp.mail=sean.middleditch@gmail.com; dkim=pass header.i=@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:11319 Archived-At: On Fri, Jun 13, 2014 at 8:34 PM, Jeremy Maitin-Shepard wrote: > 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: Is it? I perhaps am interpreting "array view" fairly narrowly, but is it really needed as a distinct concept/type from ranges of iterators? Concrete reasons? > 1. should it be represented as (begin,size) or (begin,end) [doesn't really > matter, and possibly could be implementation-defined even] The latter case seems far better suited since then the type could be used for any pair of iterators. Why make a type that works just for contiguous arrays when it could also work for vector, deque, list, map, and so on? Specializations for ranges over random-access iterators can of course offer improved performance or small functionality improvements compared to ranges over other iterator categories, just like they do for iterators today. > 2. what to call it This is a very minor detail that is dependent on several other factors that are hardly set in stone. > 3. what methods/functions should be defined for it Again, this is almost implicit in a range of iterators. The operations permitted are those allowed on the specified iterator type. If the iterator is random access, you get - and [] among others. If it's a forward iterator you get ++. The operations could be in cases renamed to pop_front, pop_back, at, etc. but those details are relatively unimportant. > Note also that it benefits from implicit conversions from types like > std::array, std::vector, std::string, etc. That's not at all a given. I for one do not want implicit conversions. Explicit is good. > 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 Eric Niebler has a great series of blog posts on this topic which you should read. There's also been plenty of discussion at the mailing list I linked earlier. > allow that as a special case for iterator_range, but then we are Or add conversion operators to vector and string. Or use an adaptor function instead of implicit conversions, which you need anyway since certain generic algorithms really want to operate on cheap-to-copy ranges and not on containers. -- --- 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/. .