220 19218 article Path: news.gmane.org!not-for-mail From: Sean Middleditch Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Overloading std::begin and std::end for std::pair Date: Thu, 23 Jul 2015 12:57:27 -0700 Lines: 246 Approved: news@gmane.org Message-ID: References: <012fd35d-96fd-4775-835e-2105176c4f97@isocpp.org> <70492682-c1ac-4d67-9c00-fe8d841aae63@isocpp.org> <424cd221-d1c7-4baf-b074-b7f44ee5c82e@isocpp.org> <58625b71-98be-4acb-9815-af1ec2113cc6@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 1437681461 19223 80.91.229.3 (23 Jul 2015 19:57:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Jul 2015 19:57:41 +0000 (UTC) Cc: rs2740@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCDODCNR2QPRBKEOYWWQKGQEKQZJUYA@isocpp.org Thu Jul 23 21:57:36 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f199.google.com ([209.85.212.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZIMcZ-0004EQ-8b for gclcip-std-proposals@m.gmane.org; Thu, 23 Jul 2015 21:57:35 +0200 Original-Received: by wixh2 with SMTP id h2sf2171982wix.0 for ; Thu, 23 Jul 2015 12:57: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:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=5K67enWIL4greLM98TXqwfmMdLe/KOSzAynviViekcg=; b=C1jR5ZBLvlyw1DRdWikCl/kTcu31wf6H1bp5ew3XWf3eaxOaxTPPuQKDwYDNQl3QeP cz+TGPHbuvnUx15ZoSFfsX90rgAaqOcv4WrgrUUYgThpSM1pbIcicvPZ6qVe6KU/Bemg 1JEfzzjYRhC0JXplsuoF/MF6iBLoHjfHmDLYko5gbWX6PkwGTaSLtckDcT4DLdoPMnyd rVqppNohEL09QlrpgvmYn1+dm5+dJ7FMeHcNJzEJV8n88fP4WalFrHoKO1UH/Z/m+6TR 7RkXftivuTm09fw0lxl6ugUytyR63WkP/jQ60fqonw8UFd8FBDq3y7qBsS5jQ4y8fSLV aqUw== X-Gm-Message-State: ALoCoQmALpCSv1o6Q3K9cs2EUkhS68G7+C5TJVT/QT19A1xWDb0fKUswhprvIfYWaDojTxPujgvB X-Received: by 10.194.93.198 with SMTP id cw6mr4517984wjb.3.1437681449781; Thu, 23 Jul 2015 12:57:29 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.10.7 with SMTP id e7ls56469wib.36.canary; Thu, 23 Jul 2015 12:57:27 -0700 (PDT) X-Received: by 10.194.248.201 with SMTP id yo9mr11053032wjc.31.1437681447926; Thu, 23 Jul 2015 12:57:27 -0700 (PDT) Original-Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com. [2a00:1450:400c:c05::236]) by mx.google.com with ESMTPS id gp7si10429731wjc.131.2015.07.23.12.57.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 12:57:27 -0700 (PDT) Received-SPF: pass (google.com: domain of sean.middleditch@gmail.com designates 2a00:1450:400c:c05::236 as permitted sender) client-ip=2a00:1450:400c:c05::236; Original-Received: by wicgb10 with SMTP id gb10so157963845wic.1 for ; Thu, 23 Jul 2015 12:57:27 -0700 (PDT) X-Received: by 10.194.85.130 with SMTP id h2mr20635842wjz.2.1437681447280; Thu, 23 Jul 2015 12:57:27 -0700 (PDT) Original-Sender: sean.middleditch@gmail.com Original-Received: by 10.27.86.148 with HTTP; Thu, 23 Jul 2015 12:57:27 -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 2a00:1450:400c:c05::236 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-Spam-Checked-In-Group: std-proposals@isocpp.org 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:19218 Archived-At: std::pair is not semantically a range. Treating it as such is wrong. Period. It _can_ be used as a range, but it would be more correct to then clearly make a semantic range type for this purpose. For member functions like equal_range, those really should return a proper range type. Returning a pair was (in hindsight) a mistake of the design. Doubling down on that mistake would just be another mistake; instead, the mistake should be corrected (whether that means changing the return type or creating new alternatives). We can't retroactively change return types without breaking compatibility (probably), but the ranges will facilitate either adding new member functions/algorithms if not an entirely new STL (with concepts + ranges). Also remember that as Eric N. pointed out, iterator pairs aren't even necessarily the best way to model ranges, esp. for some more advanced containers (instead you want iterator and sentinel type), so the existing interfaces that return a pair of iterators have yet other reasons to be replaced with proper ranges anyway. If you want your example to work easily and quickly, consider making your own quick wrapper: // wrapper template struct iterator_range : std::pair { // assuming you make an is_iterator trait; would be outmoded by concepts //static_assert(is_iterator_v); using pair::pair; T begin() { return first; } T end() { return second; } }; template iterator_range range(std::pair rng) { return iterator_range(rng); } //usage std::multimap m = { { 'A', "Apple" }, { 'A', "Animal" }, { 'A', "Amigo" }, { 'B', "Bee" }, { 'B', "Beef" }, {'B', "Brother" } }; auto it = m.equal_range( 'A' ); for ( auto p : range(it) ) std::cout << p.first << ' ' << p.second << std::endl; Short version: I strongly dislike the idea of begin/end for a pair of iterators as that's semantically incorrect and enables dangerous/broken code to compile with other pairs of iterators that don't form a range. On Thu, Jul 23, 2015 at 12:35 PM, Vlad from Moscow wrote: > How is it related to std:;pair?! You can with the same success use iterators > in any algorithm that do not make a range and what? Do you suggest not to > use algorithms? > > > On Thursday, July 23, 2015 at 10:29:23 PM UTC+3, T. C. wrote: >> >> They existed in an earlier C++0x draft, and were removed by that LWG issue >> before C++11 was published. >> >> Not all pairs of iterators are ranges. Not even all pairs of iterators >> returned by functions in the standard library are ranges, >> as your own code with minmax_element demonstrates. >> >> Besides, a range class that wraps a pair of iterators is trivial to >> implement. >> >> On Thursday, July 23, 2015 at 3:15:05 PM UTC-4, Vlad from Moscow wrote: >>> >>> There is nothing said about introducing functions std::begin and std:;end >>> for std::pair. >>> >>> On Thursday, July 23, 2015 at 9:52:23 PM UTC+3, T. C. wrote: >>>> >>>> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1381 >>>> >>>> >>>> On Thursday, July 23, 2015 at 2:30:02 PM UTC-4, Vlad from Moscow wrote: >>>>> >>>>> And one more example :) >>>>> >>>>> #include >>>>> #include >>>>> #include >>>>> #include >>>>> #include >>>>> >>>>> namespace std >>>>> { >>>>> template >>>>> Iterator begin( const std::pair &p ) >>>>> { >>>>> return p.first; >>>>> } >>>>> template >>>>> Iterator end( const std::pair &p ) >>>>> { >>>>> return p.second; >>>>> } >>>>> } >>>>> int main() >>>>> { >>>>> std::vector v = { 3, 4, 0, 5, 1, 6, 9, 7, 8 }; >>>>> >>>>> for ( auto x : v ) std::cout << x << ' '; >>>>> std::cout << std::endl; >>>>> auto p = std::minmax_element( v.begin(), v.end() ); >>>>> >>>>> if ( std::distance( v.begin(), p.second ) < std::distance( >>>>> v.begin(), p.first ) ) >>>>> { >>>>> std::swap( p.first, p.second ); >>>>> } >>>>> for ( auto x : p ) std::cout << x << ' '; >>>>> std::cout << std::endl; >>>>> } >>>>> >>>>> The program output is >>>>> >>>>> 3 4 0 5 1 6 9 7 8 >>>>> 0 5 1 6 >>>>> >>>>> On Thursday, July 23, 2015 at 8:57:38 PM UTC+3, Vlad from Moscow wrote: >>>>>> >>>>>> Another example >>>>>> >>>>>> #include >>>>>> #include >>>>>> #include >>>>>> >>>>>> namespace std >>>>>> { >>>>>> >>>>>> template >>>>>> Iterator begin( const std::pair &p ) >>>>>> { >>>>>> return p.first; >>>>>> } >>>>>> >>>>>> template >>>>>> Iterator end( const std::pair &p ) >>>>>> { >>>>>> return p.second; >>>>>> } >>>>>> >>>>>> } >>>>>> >>>>>> int main() >>>>>> { >>>>>> std::vector v = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }; >>>>>> >>>>>> for ( auto x : std::make_pair( v.begin(), v.end() ) ) std::cout << >>>>>> x << ' '; >>>>>> std::cout << std::endl; >>>>>> >>>>>> for ( auto x : std::make_pair( v.rbegin(), v.rend() ) ) std::cout >>>>>> << x << ' '; >>>>>> std::cout << std::endl; >>>>>> } >>>>>> >>>>>> The program output is >>>>>> >>>>>> 0 1 2 3 4 5 6 7 8 9 >>>>>> 9 8 7 6 5 4 3 2 1 0 >>>>>> >>>>>> Enjoy!:) >>>>>> >>>>>> On Thursday, July 23, 2015 at 8:36:46 PM UTC+3, Vlad from Moscow >>>>>> wrote: >>>>>>> >>>>>>> I'd like to suggest very simple and at the same time very useful >>>>>>> overloaded functions std::begin and std::end for standard class std::pair. >>>>>>> >>>>>>> Here is a demonstrative program of the idea >>>>>>> >>>>>>> #include >>>>>>> #include >>>>>>> >>>>>>> namespace std >>>>>>> { >>>>>>> template >>>>>>> Iterator begin( const std::pair &p ) >>>>>>> { >>>>>>> return p.first; >>>>>>> } >>>>>>> template >>>>>>> Iterator end( const std::pair &p ) >>>>>>> { >>>>>>> return p.second; >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> int main() >>>>>>> { >>>>>>> int a[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }; >>>>>>> >>>>>>> for ( auto x : std::make_pair( a + 3, a + 7 ) ) std::cout << x << >>>>>>> ' '; >>>>>>> std::cout << std::endl; >>>>>>> >>>>>>> int b[][3] = { { 1, 2, 3 }, { 4, 5, 6 } }; >>>>>>> >>>>>>> for ( auto x : std::make_pair( b[0] + 1, b[1] + 2 ) ) std::cout >>>>>>> << x << ' '; >>>>>>> std::cout << std::endl; >>>>>>> } >>>>>>> >>>>>>> The program output is >>>>>>> >>>>>>> 3 4 5 6 >>>>>>> 2 3 4 5 > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/isocpp.org/d/topic/std-proposals/z_BtdcvO1NA/unsubscribe. > To unsubscribe from this group and all its topics, 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/. -- Sean Middleditch http://seanmiddleditch.com -- --- 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/. .