220 4854 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Proposal: std::sequence Date: Tue, 4 Jun 2013 11:41:43 -0700 (PDT) Lines: 175 Approved: news@gmane.org Message-ID: 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_3970_25767685.1370371303582" X-Trace: ger.gmane.org 1370371305 7230 80.91.229.3 (4 Jun 2013 18:41:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Jun 2013 18:41:45 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBB2PJXCGQKGQESZUPVMI@isocpp.org Tue Jun 04 20:41:47 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f200.google.com ([209.85.223.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UjwB0-0000lV-Cu for gclcip-std-proposals@m.gmane.org; Tue, 04 Jun 2013 20:41:46 +0200 Original-Received: by mail-ie0-f200.google.com with SMTP id k5sf2892301iea.11 for ; Tue, 04 Jun 2013 11:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=975ffmJorfKvbYc5sINwFZSyhCRuJkI3iGluYLwsli8=; b=ViyR7xkZOksvrtrpqUyYn6jo3M40iXphUEVKMmlE/6EhPTiITfxx2fZS+ZI3ww9sP+ gF2cXrnCAk5zkqSUfK7rLa08jdD0H0hWJFIvDtzoUKjEzpTEPeSjmO7Pg7txdAZEiB8F PVIAt4HnNcG8tIGPkwJb8pC5CmyrZc++eV27k9PToRCwZvLQP1SeJx5LsvKjI1m6U+Jc YYlizWIrAauQ1Yb838FEejXmQAdCVjguQg0P8RQGsI8XPUvMTRmH7ljcvxxWGP2Xo4xV 5O9uupDogu/n8D3Cen+TIjThlG9OPEiFuyiieEZfKUFCETuYAabLp0yIN/Bm7vl+S/7R AL7Q== X-Received: by 10.50.50.33 with SMTP id z1mr1906362ign.6.1370371305539; Tue, 04 Jun 2013 11:41:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.72.39 with SMTP id a7ls529515igv.37.gmail; Tue, 04 Jun 2013 11:41:44 -0700 (PDT) X-Received: by 10.50.36.41 with SMTP id n9mr351595igj.11.1370371304530; Tue, 04 Jun 2013 11:41:44 -0700 (PDT) In-Reply-To: <1c991e6e-6bc3-4822-9ffd-7f2508e63974@isocpp.org> X-Original-Sender: jmckesson@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:4854 Archived-At: ------=_Part_3970_25767685.1370371303582 Content-Type: text/plain; charset=ISO-8859-1 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 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. -- --- 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_3970_25767685.1370371303582 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tuesday, June 4, 2013 7:27:59 AM UTC-7, carrieran...@yahoo.co.uk wrote:<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">On Monday, June 3, 2013 6:39:35= PM UTC-4, Nicol Bolas wrote:
On Mon= day, June 3, 2013 1:24:54 PM UTC-7, carrieran...@yahoo.co.uk wrote:<= br>
re Lightweight: The smalles= t array_ref could be the same size as a sequence. Because array_ref's membe= rs 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 m= y math. What exactly is your question?

Felipe co= vered this one, but I'll reiterate. You claimed that array_ref's members no= t being `const` would make code "larger and slower". How? In what cases cou= ld that possibly happen?

Shrinking did not exist in my proposal because I never ne= eded that functionality. I was content with the guarantees the type provide= d 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 aga= in that Google and LLVM do need this functionality. They didn't writ= e those functions just because they could. Does your class get as much usag= e 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 ob= jections are these:

1: The committee already saw a proposal that was= similar to what you suggest. A proposal that was rejected (for reasons tha= t I find dubious, but nevermind that now).

2: Your proposal is not d= ifferent enough from the rejected one to likely gain any traction with the = committee. Especially over the solution that many committee members apparen= tly prefer (ie: wait for ranges/traversal/etc and hope that they sol= ve the problem).

3: Your proposal, when compared to the rejected one= , is a needless step backwards. The standard must serve more needs than jus= t your own. While the fact that you haven't needed to modify these "sequenc= es" is interesting, the fact that other people clearly do have that = need outweighs that. And most notably, the apparently committee-preferred s= olution (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 reali= ze that there is a call for library proposals and that this is the forum fo= r such proposals: "The door is open for submissions of features to be added to t= he standard library, and we would love to see them not only from existing c= ommunity libraries like Boost, Poco, and Qt, but from you.".&nbs= p;Proposals don't need your endorsement watchdogging. Let's stay squarely o= n topic.

This forum is for commentary on proposa= ls 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 t= hem better before proposing them. Not agreeing with commentary does not mak= e that commentary invalid.

I'm not stopping you from writing up a pr= oposal and submitting it. But I'm not going to pretend that I think it woul= d be a worthwhile use of the committee's time debating and voting on it eit= her, compared to either getting array_ref back or the apparently committee = preferred solution.

--
 
---
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_3970_25767685.1370371303582-- .