220 11325 <1f2e4abf-7391-492a-b505-555936904231@isocpp.org> 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: Sat, 14 Jun 2014 10:29:26 -0700 (PDT) Lines: 225 Approved: news@gmane.org Message-ID: <1f2e4abf-7391-492a-b505-555936904231@isocpp.org> 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_833_17626815.1402766966662" X-Trace: ger.gmane.org 1402766980 15076 80.91.229.3 (14 Jun 2014 17:29:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Jun 2014 17:29:40 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCYZZ4E5WQCRB6EM6KOAKGQED3JZT4I@isocpp.org Sat Jun 14 19:29:30 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qa0-f69.google.com ([209.85.216.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wvrli-00084J-59 for gclcip-std-proposals@m.gmane.org; Sat, 14 Jun 2014 19:29:30 +0200 Original-Received: by mail-qa0-f69.google.com with SMTP id w8sf11960852qac.4 for ; Sat, 14 Jun 2014 10:29:29 -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=mQ2A/NbaRvthtm5spREKq8yRdjVx7EpSutvgm3VwvEw=; b=g8IPYhY6DVvXJY9fN3wdIzQgsSq96MmxXktshXgwrF3/KO+h2ZTS5asFwhoQXZpWWo E3MVJAJfW60gpiIcIJAyZoAZlfFtAacSMcKalli5aoKruh7n5M+y/2qCoBRPyjzNsiiV eHc0ILHfNZO147z2AiKcf/JEXrRN1V1WSvJI8rJ+nTgiTkLYgFs20/ZwkrZ9GJLqkC1G SLgZzFfprUSMjk3dAdn5aBR4xNOQ0Q9wccS+k5aH2PpaBVVbbnooyOsgGeEfXV1Xy1FG vukezbHgebOpXJLYYzyCOI3fWvwMDEZpTgQur6H+5dAJzGrGkVhIK3zTWX8thmVOOWBP rPOA== X-Gm-Message-State: ALoCoQnNjkKUVVGcgfM6hx+QL39Dpzn4W39aRSeP4MHGvncQVlcwRfWsBPkIb9zFuOquQw0PY+/q X-Received: by 10.236.31.40 with SMTP id l28mr3873095yha.34.1402766969371; Sat, 14 Jun 2014 10:29:29 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.3.7 with SMTP id 7ls247882igy.19.canary; Sat, 14 Jun 2014 10:29:28 -0700 (PDT) X-Received: by 10.50.17.100 with SMTP id n4mr229473igd.3.1402766968336; Sat, 14 Jun 2014 10:29:28 -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:11325 Archived-At: ------=_Part_833_17626815.1402766966662 Content-Type: text/plain; charset=UTF-8 On Saturday, June 14, 2014 2:06:12 AM UTC-7, Sean Middleditch wrote: > > 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? > The only way it is special, as far as I am concerned, is the implicit conversions. It needs to have a name, rather than just be a concept, so that it can be used in non-template interfaces. It could just use the same name as iterator_range but have the implicit conversions added when the iterator is a pointer. It does seem there is a higher risk of these implicit conversions causing problems in generic code than if they were only present on a separate array_view type. I don't have any specific issue in mind, though. > > > 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. I agree. > > > > 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. > I agree. > > > 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. > I agree with you in general. However, this doesn't seem to be the general sentiment for string_view, and it is useful for array_view for the same reasons as string_view. Most notably, so that it can be conveniently used as a function parameter type. In that case it really would be no more dangerous than a reference type. As you say below, the same can be achieved by adding the conversions to the source types instead, except for builtin arrays. The one downside is that it is impossible to gain user experience with the facility as a pure extension library, e.g. in boost, since the conversions would require modifying existing standard library components. Also, given the special case for builtin arrays, it seems you might as well special case some other standard library types. > > 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. > I did read his blog posts previously. I don't recall them contradicting the utility of a basic iterator_range type. -- --- 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_833_17626815.1402766966662 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Saturday, June 14, 2014 2:06:12 AM UTC-7, Sean Middledi= tch wrote:
On Fri, Jun 13, 2014= at 8:34 PM, Jeremy Maitin-Shepard
<jer...@jeremyms.com> wr= ote:
> You may be right, that it would be redundant with some range-relat= ed
> facility, and any array_view proposal should probably be seen as t= entative
> 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?
The only way it is special, as f= ar as I am concerned, is the implicit conversions.  It needs to have a= name, rather than just be a concept, so that it can be used in non-templat= e interfaces.  It could just use the same name as iterator_range but h= ave the implicit conversions added when the iterator is a pointer.  It= does seem there is a higher risk of these implicit conversions causing pro= blems in generic code than if they were only present on a separate array_vi= ew type.  I don't have any specific issue in mind, though.
 

> 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.
I agree.


> 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.
I agree.

> Note also that it benefits from implicit conversions from types li= ke
> 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.
I agree with you in general.  However, this does= n't seem to be the general sentiment for string_view, and it is useful for = array_view for the same reasons as string_view.  Most notably, so that= it can be conveniently used as a function parameter type.  In that ca= se it really would be no more dangerous than a reference type.

As yo= u say below, the same can be achieved by adding the conversions to the sour= ce types instead, except for builtin arrays.  The one downside is that= it is impossible to gain user experience with the facility as a pure exten= sion library, e.g. in boost, since the conversions would require modifying = existing standard library components.  Also, given the special case fo= r builtin arrays, it seems you might as well special case some other standa= rd library types.


> It is also clear that we need an iterator_range type similar to
> boost::iterator_range, regardless of what alternate range models m= ay also
> exist.  (However, it could be useful to allow the begin and e= nd iterators to
> optionally have different types.)  Therefore, we can be fairl= y 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.

I did read his blog posts previously.  I don= 't recall them contradicting the utility of a basic iterator_range type.

--

---
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_833_17626815.1402766966662-- .