220 15326 <00940b5e-fa33-43f5-961d-e9b42b3565b9@isocpp.org> article Path: news.gmane.org!not-for-mail From: Leo Heinsaar Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Isn't it time we had the bool std::[container]::contains() family of methods? Date: Fri, 26 Dec 2014 09:33:49 -0800 (PST) Lines: 143 Approved: news@gmane.org Message-ID: <00940b5e-fa33-43f5-961d-e9b42b3565b9@isocpp.org> References: <0959f2f8-acdd-4786-b6f3-0f05c62dcee6@isocpp.org> <2df86492-548f-42c8-86d6-fe1c8ba3a5a9@isocpp.org> <2f390ec3-b259-4150-9771-cd0d02860348@isocpp.org> <3743ebda-3367-4fc3-922a-f38d98e57889@isocpp.org> <1bccb2dd-4aa4-4f07-8958-b1d6bf092630@isocpp.org> <46cc4da5-98d1-471f-ab31-714ac5502853@isocpp.org> <136dcbcc-7fff-4e30-9852-5554cc743a42@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_311_1333924014.1419615229773" X-Trace: ger.gmane.org 1419615243 16662 80.91.229.3 (26 Dec 2014 17:34:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Dec 2014 17:34:03 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCFYDAXXQYEBB7VX62SAKGQEBNBGJAI@isocpp.org Fri Dec 26 18:33:52 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f199.google.com ([209.85.213.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y4Yls-0001Ep-0R for gclcip-std-proposals@m.gmane.org; Fri, 26 Dec 2014 18:33:52 +0100 Original-Received: by mail-ig0-f199.google.com with SMTP id hl2sf57193957igb.10 for ; Fri, 26 Dec 2014 09:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=NHWpxfzgXpxZq01aPzhto1/yMljrg5USEZEq2MyBC4k=; b=HGqW3f2XKS8uHe5j2ciMyLiIh0+J6RgK8hY0Tp6UVQS37ns5HQhSUAHfyH7xOZpCGo Qm7pnHg+g3zM2pEh0lRsAHZqrN4jb3N53MDPRkilXQZyokgTW1/exSg/AQrx4yW2Ofos UZ1nZQXdj/8Y3No1msrvkFvRceStr3wbYif7PLs2mi8P3d9j+uiFB4O82nTfeG8R4IAo z+R3JmLDsX9tGSh81Hcsbu2g92LHRXAnvZn6MZoSA4FWeYD1Y28AsgRc/CJQOmlyzZWK jUlmLVmJR/pMEQWR9wi3kKOB4R72pURkNAmVDrUFlB7mvR3zUZP0HqTKZsbhrGNre+vE Fp5A== 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:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=NHWpxfzgXpxZq01aPzhto1/yMljrg5USEZEq2MyBC4k=; b=PhdjvXyp0rguGm+ZtEfAyvNXcfqgsNyp38TZSp7Eq/cyGW3jmqW57fCuQ9q0zzif2c Tu3yfjOtTdDLnqoqTZ7m4FmnwVjAXG1SEsVTNA+pWJAXE8SmaWM7iyHbMuvpd9OidRWv E0HFcaehvKVQM3gDsgma/tmQbQkRtIXrptIQ9hi+zwTHRrQ0eyYLlF1Fnj0/9IfeybqT kliK4GNFVtmDruzCOeQVnmgvdIcmBrLzTZCQdNpwvnkIgPziS0Udx4GNVlQss1M3vuO7 EmoUlTa1DyWp2lRqCGZFJUXvJDHgbS3oc+m/M7uK4pLpBbV1zYBswr/bjeVBLr2xF6iN 2axw== X-Gm-Message-State: ALoCoQm8LM2NbEOUypa/5trSK1h6Q0z86fCc8nPL9jyGfFkuEhtxyrO3dKpkg7eYnUCAabEz6gPx X-Received: by 10.42.20.3 with SMTP id e3mr35372129icb.11.1419615230930; Fri, 26 Dec 2014 09:33:50 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.83.232 with SMTP id j95ls4486116qgd.39.gmail; Fri, 26 Dec 2014 09:33:50 -0800 (PST) X-Received: by 10.140.36.134 with SMTP id p6mr21107qgp.16.1419615230201; Fri, 26 Dec 2014 09:33:50 -0800 (PST) In-Reply-To: <136dcbcc-7fff-4e30-9852-5554cc743a42@isocpp.org> X-Original-Sender: leoheinsaar@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:15326 Archived-At: ------=_Part_311_1333924014.1419615229773 Content-Type: multipart/alternative; boundary="----=_Part_312_1679112265.1419615229773" ------=_Part_312_1679112265.1419615229773 Content-Type: text/plain; charset=UTF-8 > > How is it less typing? Auto-complete? >>> >> >> Since we'll be able to simply write >> >> *phone_book.contains(number)* >> >> instead of: >> >> *phone_book.find(number) != phone_book.end()* >> >> Not to mention how much more clearly the simplified version, as they like >> to call it, expresses intent. >> > > I think Olaf meant to ask what is the advantage of the v.contains(x) > syntax over the contains(v, x) syntax in terms of typing. In fact, there is > not much of an advantage apart from auto-completion (as Olaf suggests). > You're right Andy - I misunderstood. > > IMO we shouldn't focus much on minimizing the amount of *typing*: it is > not *that* important for code to be easy to write as it is to be easy to > read. We read and reason about code much more frequently than we write it, > and constantly aiming for the least number of keystrokes is not a good > practice and it does not help reasoning about the result of our typing (see > the several discussions on intent-revealing names, small extracted > functions, etc.). > Actually, the whole reason that led to the opening of this topic is precisely because I kept seeing so many *"...!= end()"s* when trying to *read *and understand our code. Also, it seems to me that *less typing* is directly proportional to *easy reading*. For example, when I try to figure out what some of our very loopy code does, I rewrite all the loops in range-fors and get rid of all the iterators. It really does give me the birds-eye view of the intent of the code so I read and navigate the logic much easier. Of course, neither range-fors nor autos were introduced to *minimize typing*, but thankfully less typing *did* come with them, and that simplifies reading - greatly. > > This said, there are situations where the dot notation would make code > easy to read (not sure this is one of them though), e.g. when composing > algorithms that work on ranges. This is why I think it is worth considering > UFCS proposals. As a side-effect, this would bring us more flexibility (and > possibly more consistency) in choosing the best syntax for function calls. > > Kind regards, > > Andy > -- --- 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_312_1679112265.1419615229773 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How is it less typing? Auto-complete?

Since we'll be able to simply write
= phone_book.contains(number)
instead of:
phone_book.f= ind(number) !=3D phone_book.end()
Not to = mention how much more clearly the simplified version, as they like to call = it, expresses intent.

I think Olaf meant t= o ask what is the advantage of the v.contains(x) syntax over the contains(v= , x) syntax in terms of typing. In fact, there is not much of an advantage = apart from auto-completion (as Olaf suggests).

You're right Andy - I misunderstood.
 <= /div>
IMO we shouldn't focus much on minimizing the amount of typing: it = is not that important for code to be easy to write as it is to be ea= sy to read. We read and reason about code much more frequently than we writ= e it, and constantly aiming for the least number of keystrokes is not a goo= d practice and it does not help reasoning about the result of our typing (s= ee the several discussions on intent-revealing names, small extracted funct= ions, etc.).

Actually, the = whole reason that led to the opening of this topic is precisely because I k= ept seeing so many "...!=3D end()"s when trying to read = and understand our code. Also, it seems to me that less typing&= nbsp;is directly proportional to easy reading. For example, whe= n I try to figure out what some of our very loopy code does, I rewrite all = the loops in range-fors and get rid of all the iterators. It really does gi= ve me the birds-eye view of the intent of the code so I read and navigate t= he logic much easier. Of course, neither range-fors nor autos were introduc= ed to minimize typing, but thankfully less typing did come wi= th them, and that simplifies reading - greatly. 
 

Thi= s said, there are situations where the dot notation would make code easy to= read (not sure this is one of them though), e.g. when composing algorithms= that work on ranges. This is why I think it is worth considering UFCS prop= osals. As a side-effect, this would bring us more flexibility (and possibly= more consistency) in choosing the best syntax for function calls.

K= ind regards,

Andy

--

---
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_312_1679112265.1419615229773-- ------=_Part_311_1333924014.1419615229773-- .