220 4865 <1a298dfc-9fb0-4124-9ad5-4b3afc3afa3f@isocpp.org> article Path: news.gmane.org!not-for-mail From: carrierandoperator@yahoo.co.uk Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Proposal: std::sequence Date: Tue, 4 Jun 2013 16:13:04 -0700 (PDT) Lines: 596 Approved: news@gmane.org Message-ID: <1a298dfc-9fb0-4124-9ad5-4b3afc3afa3f@isocpp.org> References: <4551abbc-43aa-4520-a91a-f8eb25a90588@isocpp.org> <2c8e6079-9c87-425a-93e2-39251df57cd8@isocpp.org> <9f1cace3-0503-4a3c-a8ce-d7546564b3ef@isocpp.org> <1c991e6e-6bc3-4822-9ffd-7f2508e63974@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1036_11401103.1370387584888" X-Trace: ger.gmane.org 1370387587 15816 80.91.229.3 (4 Jun 2013 23:13:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Jun 2013 23:13:07 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDQ2R4E5RIKBBAXJXGGQKGQEZNNLZDQ@isocpp.org Wed Jun 05 01:13:08 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qa0-f72.google.com ([209.85.216.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Uk0Pb-0001Qq-QY for gclcip-std-proposals@m.gmane.org; Wed, 05 Jun 2013 01:13:08 +0200 Original-Received: by mail-qa0-f72.google.com with SMTP id bs12sf1471754qab.7 for ; Tue, 04 Jun 2013 16:13:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-beenthere:date:from:to: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=WHefMPeZuY6Ml/s4FnI1Dc6UpHrroxo0RMPduPQHu9E=; b=nUFNkg3d4hdxV0DdI64HxXiheiaVn//6ftsN1iYTvvinm2QvwkUISKyxyyppEh8ACx ucrmTFp77whQmhaPW064emIviQIU0GQ/vjtBiNcuiSePh7f/PpmO3p22tSU2YgcGpSsN LaN7Q5wrzkGkcYm7pxdRhYeQ7K6F4Y5HPW2r6OsddOuARAht+Ph7rpdtnEZ6lrG0ygCT KXy1/en9THWxxS0K71Rhl8tRnqm1hQO24vk315usv29FRiWM3bhXjp++lSh9+y5+roy/ LEDoh6HPZ/v2ZI3Elgm5mJtYKOZg+eWQ031P0bCra2s44g3GaFinePCU6eCRHkKtvwH+ cSMw== X-Received: by 10.224.174.145 with SMTP id t17mr17506700qaz.4.1370387586906; Tue, 04 Jun 2013 16:13:06 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.117.104 with SMTP id kd8ls605308qeb.93.gmail; Tue, 04 Jun 2013 16:13:05 -0700 (PDT) X-Received: by 10.49.24.37 with SMTP id r5mr2187618qef.10.1370387585237; Tue, 04 Jun 2013 16:13:05 -0700 (PDT) In-Reply-To: X-Original-Sender: carrierandoperator@yahoo.co.uk 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:4865 Archived-At: ------=_Part_1036_11401103.1370387584888 Content-Type: text/plain; charset=ISO-8859-1 On Tuesday, June 4, 2013 2:41:43 PM UTC-4, Nicol Bolas wrote: > > On Tuesday, June 4, 2013 7:27:59 AM UTC-7, carrieran...@yahoo.co.uk wrote: >> >> On Monday, June 3, 2013 6:39:35 PM UTC-4, Nicol Bolas wrote: >>> >>> On Monday, June 3, 2013 1:24:54 PM UTC-7, carrieran...@yahoo.co.ukwrote: >>> >>>> re Lightweight: The smallest array_ref could be the same size as a >>>> sequence. Because array_ref's members are not const, it could result in >>>> larger and slower code. >>>> >>> >>> ... how? They'll just be a pair of pointers or a pointer+size either way. >>> >> >> So you have checked my math. What exactly is your question? >> > > Felipe covered this one, but I'll reiterate. You claimed that array_ref's > members not being `const` would make code "larger and slower". How? In what > cases could that possibly happen? > > Shrinking did not exist in my proposal because I never needed that >>>> functionality. I was content with the guarantees the type provided and its >>>> simplicity. The type did not attempt to be an iterator, range, or scanner >>>> as well. I've found slicing quite effective. >>>> >>> >>> I don't really see how that's an argument, especially considering again >>> that Google and LLVM *do* need this functionality. They didn't write >>> those functions just because they could. Does your class get as much usage >>> as all internal Google and LLVM C++ projects? If not, then I would rather >>> defer to the guys who have the usage experience. >>> >> >> Since explaining this to you, endorsement comes out as the heart of your >> objection? >> > > No, the heart of my objections are these: > > 1: The committee already saw a proposal that was similar to what you > suggest. A proposal that was rejected (for reasons that I find dubious, but > nevermind that now). > > 2: Your proposal is not different enough from the rejected one to likely > gain any traction with the committee. Especially over the solution that > many committee members apparently prefer (ie: wait for ranges/traversal/etc > and hope that *they* solve the problem). > > 3: Your proposal, when compared to the rejected one, is a needless step > backwards. The standard must serve more needs than just your own. While the > fact that you haven't needed to modify these "sequences" is interesting, > the fact that *other* people clearly do have that need outweighs that. > And most notably, the apparently committee-preferred solution (ie: > iterator_range) is quite mutable, if it's based on the > boost::iterator_range. > So that's LLVM, Google, *and* Boost, all of whom think mutability is > important. > > You need to realize that there is a call for library proposals and that >> this is the forum for such proposals: "The door is open for submissions >> of features to be added to the standard library, and we would love to see >> them not only from existing community libraries like Boost, Poco, and Qt, >> but from *you*.". Proposals >> don't need your endorsement watchdogging. Let's stay squarely on topic. >> > > This forum is for commentary on proposals and inquiry on proposals, so as > to either fix issues in proposals (like not being able to modify the > object) or to otherwise refine them and make them better before proposing > them. Not agreeing with commentary does not make that commentary invalid. > > I'm not stopping you from writing up a proposal and submitting it. But I'm > not going to pretend that I think it would be a worthwhile use of the > committee's time debating and voting on it either, compared to either > getting array_ref back or the apparently committee preferred solution. > 0. I've just responded to Felipe. 1. I've not followed all the proposals. I didn't know of array_ref when I proposed. Its proposal also preceded the open call (perhaps it's a bit dusty at this point). I will have to look for the reason concerning its rejection. 2. Ok. Thanks for the heads up. I plan to float a more concrete iteration in a few days (more below). 3. You can easily refer to a slice of the sequence or request an iterator from it -- seems more logical to hoist the implementation out to a type dedicated to the given problem (e.g. iterator). Don't forget that sequences offer mutable elements while array_ref does not. IMO, mutable elements offer greater applicability than array_ref's shrinking and assignment. Because of this distinction, one could say that sequences more accurately resemble llvm's ArrayRef and MutableArrayRef than the proposed array_ref. I tried to explain how that step forward combined with the step "backwards" makes for what I consider very clean semantics in use, but here's how it unfolds: === Array Refs === void foo(array_ref p); // foo can shrink either end of p or reassign p. of course, that change is local to the function. void foo(array_ref& p); // foo can shrink either end of p or reassign p, and the caller will see that change void foo(const array_ref p); // foo can read the elements and the size void foo(const array_ref& p); // foo can read the elements and the size In no case can foo alter the array elements. === Sequences === void foo(sequence p); void foo(sequence& p); void foo(const sequence p); void foo(const sequence& p); In all cases, foo() can access the elements, but not mutate them. void foo(mutable_sequence p); void foo(mutable_sequence& p); In both cases, foo() can read and mutate the elements. void foo(const mutable_sequence p); void foo(const mutable_sequence& p); In both cases, foo() can access the elements, but not mutate them. === Practical comparison with redundance eliminated === === Array Refs === void foo(array_ref p); // foo can shrink either end of p or reassign p. of course, that change is local to the function. void foo(array_ref& p); // foo can shrink either end of p or reassign p, and the caller will see that change. void foo(const array_ref p); // foo can read the elements and the size. In no case can foo alter the array elements. === Sequences === void foo(sequence p); // foo() can access the elements, but not mutate them. void foo(mutable_sequence p); // foo() can access the elements and also mutate them. For foo(const mutable_sequence) and foo(const mutable_sequence& p) one would just declare void foo(sequence p) instead. === End Practical comparison === Anyways, I should just make a more concrete representation of this for you all before we spend more time on the shrink/assign issue. If there is interest at that stage, I think the next logical step would be for me to float a basic implementation you all can try out where features such as assignment can be enabled via the preprocessor. In essence, that would change members from: template<>class sequence {T* const elements; const size_t size;}; to: template<>class sequence {T* elements; size_t size;}; Thus adding the following to practical signatures: void foo(sequence& p); // foo() can access the elements, but not mutate them. p may be shrunk or reassigned. void foo(mutable_sequence& p); // foo() can access the elements and also mutate them. p may be shrunk or reassigned. Adding sequences isn't for my personal benefit; I mentioned I already have an implementation. Sure, it would help in some cases outside of my codebase but I don't see how sequences serve me more than it would serve anybody in this group. Glad we could bring this back on track. -- --- 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/?hl=en. ------=_Part_1036_11401103.1370387584888 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tuesday, June 4, 2013 2:41:43 PM UTC-4, Nicol Bolas wrote:On Tuesday, June 4, 2013 7:27:59 AM = UTC-7, carrieran...@yahoo.co.uk wrote:
On Monday, June 3, 2013 6:39:35 PM UTC-4, Nicol Bolas wrote:On Monday, June 3, 2013 1:24:54 PM UTC-7= , carrieran...@yahoo.co.uk wrote:
re Lightweight: The smallest array_ref could be the same size= as a sequence. Because array_ref's members are not const, it could result = in larger and slower code.

... how? They'll just= be a pair of pointers or a pointer+size either way.
=

So you have checked my math. What exactly is your quest= ion?

Felipe covered this one, but I'll reiterate= .. You claimed that array_ref's members not being `const` would make code "l= arger and slower". How? In what cases could that possibly happen?

Shrinking did not exi= st in my proposal because I never needed that functionality. I was content = with the guarantees the type provided and its simplicity. The type did not = attempt to be an iterator, range, or scanner as well. I've found slicing qu= ite effective.

I don't really see how that's an = argument, especially considering again that Google and LLVM do need = this functionality. They didn't write those functions just because they cou= ld. Does your class get as much usage as all internal Google and LLVM C++ p= rojects? If not, then I would rather defer to the guys who have the usage e= xperience.

Since explaining this = to you, endorsement comes out as the heart of your objection?

No, the heart of my objections are these:

1: The commi= ttee already saw a proposal that was similar to what you suggest. A proposa= l that was rejected (for reasons that I find dubious, but nevermind that no= w).

2: Your proposal is not different enough from the rejected one t= o likely gain any traction with the committee. Especially over the solution= that many committee members apparently prefer (ie: wait for ranges/travers= al/etc and hope that they solve the problem).

3: Your proposa= l, when compared to the rejected one, is a needless step backwards. The sta= ndard must serve more needs than just your own. While the fact that you hav= en't needed to modify these "sequences" is interesting, the fact that ot= her people clearly do have that need outweighs that. And most notably, = the apparently committee-preferred solution (ie: iterator_range) is quite m= utable, if it's based on the boost::iterator_range. So that's LLVM, Google, and B= oost, all of whom think mutability is important.

You need to realize that there is a call fo= r library proposals and that this is the forum for such proposals: "The door is= open for submissions of features to be added to the standard library, and = we would love to see them not only from existing community libraries like B= oost, Poco, and Qt, but from you.". Proposals don't need yo= ur endorsement watchdogging. Let's stay squarely on topic.

This forum is for commentary on proposals and inquiry on proposa= ls, so as to either fix issues in proposals (like not being able to modify = the object) or to otherwise refine them and make them better before proposi= ng them. Not agreeing with commentary does not make that commentary invalid= ..

I'm not stopping you from writing up a proposal and submitting it.= But I'm not going to pretend that I think it would be a worthwhile use of = the committee's time debating and voting on it either, compared to either g= etting array_ref back or the apparently committee preferred solution.

0. I've just responded to Felipe.

1. I've not followed all the proposals. I didn't know = of array_ref when I proposed. Its proposal also preceded the open call (per= haps it's a bit dusty at this point). I will have to look for the reason co= ncerning its rejection.

2. Ok. Thanks for the head= s up. I plan to float a more concrete iteration in a few days (more below).=

3. You can easily refer to a slice of the sequenc= e or request an iterator from it -- seems more logical to hoist the impleme= ntation out to a type dedicated to the given problem (e.g. iterator). Don't= forget that sequences offer mutable elements while array_ref does not. IMO= , mutable elements offer greater applicability than array_ref's shrinking a= nd assignment. Because of this distinction, one could say that sequences mo= re accurately resemble llvm's ArrayRef and MutableArrayRef than the propose= d array_ref. I tried to explain how that step forward combined with the ste= p "backwards" makes for what I consider very clean semantics in use, but he= re's how it unfolds:

=3D=3D=3D Array Refs =3D=3D= =3D

void foo(array_ref<T> p); // foo can shri= nk either end of p or reassign p. of course, that change is local to the fu= nction.void foo(array_ref<T>& p); // foo can shrink either end of p or reassign p, and the caller will= see that change
= void foo(const array_ref<T> p); // foo can read the elements and the size
void foo(const array_ref<T<= /span>>& p); // foo can read the elements and the = size


In no case can foo alte= r the array elements.

=3D=3D=3D Sequences =3D=3D= =3D

void foo(sequence<T> p);
void foo(sequence<T>& p);
void foo= (const sequence<T> p);
void foo(const sequence<T>& p);


In all cases, foo() can access the elements, but not mutate them.
<= div>
void foo(mutable_sequence<T> p);=
void foo(mutable_sequence<T>& p);


In both c= ases, foo() can read and mutate the elements.

void foo(co= nst mutabl= e_sequence= <T> p);
void foo(const mutable_sequence<T&= gt;& p= );<= span style=3D"color: #000;" class=3D"styled-by-prettify">
<= /code>


In both cases, foo() can access the ele= ments, but not mutate them.

=3D=3D=3D Practical co= mparison with redundance eliminated =3D=3D=3D

=3D= =3D=3D Array Refs =3D=3D=3D

void fo= o(<= span style=3D"color: #000;" class=3D"styled-by-prettify">array_ref<T> p); // foo can shrink either end of p or reassign p. of course, that = change is local to the function.
void foo(arr= ay_ref<= T>& p); // foo can shrink either end of p or reassign= p, and the caller will see that change.
void foo(const a= rray_ref&l= t;T= > p); // foo can read the elements and the size.


In no case can foo alter the array el= ements.

=3D=3D=3D Sequences =3D=3D=3D
void foo(sequence<T&g= t; p); // foo() can access the elements,= but not mutate them.
void = foo(mutable_sequence= <T> p); // foo() can access the elements and also mutate them.
<= /div>


For foo(const mutable_sequence<= ;T>) and foo(const mutable_sequence<T>& p) one would just decl= are void foo(sequence<T> p) instead.

=3D=3D= =3D End Practical comparison =3D=3D=3D

Anyways, I = should just make a more concrete representation of this for you all before = we spend more time on the shrink/assign issue. If there is interest at that= stage, I think the next logical step would be for me to float a basic impl= ementation you all can try out where features such as assignment can be ena= bled via the preprocessor. In essence, that would change members from:

template<>class sequence {T* const elements= ; <= span style=3D"color: #008;" class=3D"styled-by-prettify">const size_t size;};


to:
template<>class seq= uence {T* elements; size_t size;};

=
Thus adding the following to practical signatures:
void foo(se= quence<= T>& p); // foo() can access the elements, but not mut= ate them. p may be shrunk or reassigned.
void foo(mutable_sequence<T>&a= mp; p); // foo() can access the elements= and also mutate them. p may be shrunk or rea= ssigned.

Adding s= equences isn't for my personal benefit; I mentioned I already have an imple= mentation. Sure, it would help in some cases outside of my codebase but I d= on't see how sequences serve me more than it would serve anybody in this gr= oup.

Glad we could bring this back on track.
=
 

--
 
---
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-pro= posals/?hl=3Den.
 
 
------=_Part_1036_11401103.1370387584888-- .