220 19317 article Path: news.gmane.org!not-for-mail From: Matthew Woehlke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Overloading std::begin and std::end for std::pair Date: Mon, 27 Jul 2015 11:11:58 -0400 Lines: 71 Approved: news@gmane.org Message-ID: References: <012fd35d-96fd-4775-835e-2105176c4f97@isocpp.org> <792fab39-5af7-4d95-b9ba-a5cc4aed8544@isocpp.org> <8100167.A1Y3soRlXn@tjmaciei-mobl4> <15e678b3-9b6b-4966-a7a5-1d37495fda5e@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 1438009964 4150 80.91.229.3 (27 Jul 2015 15:12:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2015 15:12:44 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC37LBFWUIFBBXUU3GWQKGQEZBCQDGA@isocpp.org Mon Jul 27 17:12:35 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f200.google.com ([209.85.217.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZJk4v-0005Zy-BZ for gclcip-std-proposals@m.gmane.org; Mon, 27 Jul 2015 17:12:33 +0200 Original-Received: by lbvb1 with SMTP id b1sf28668854lbv.3 for ; Mon, 27 Jul 2015 08:12:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:date:lines:message-id:references :mime-version:content-type:user-agent:in-reply-to: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=dF2XfoL48syCLlJtlVCnHFs4mRxmyN2LkSl9j7l6zN8=; b=H9fzVtDSuIfpH8tD1oahB5eTR2KCiZ9Rti1DBZNVYYf4MkFJMLPZhNNMUYoRcNyjEx kxkBxEaisXNV+f88dEtBWhyXmYaCvWA3QdJVn3tmOa4A0k2sYMKc6OuS3r/wJoLxlKOE +2XjWWV/6nPRRntRwUpbcijksf1/p2becjgrBuH3Bx5x3EU6+/zSUFa5C6J1P1z65AwF P07Nwe3OmKQEp6vN18oPaa+jRXRByEIh/RTt3hMEXJ4iVbqtnTBRBQq1tNxfTweCj3lq jblgYY0EgukreBItQwzTRVtqN9xxY0FVAcIuOIGXmfyqwgqYrJg4kT/3KvR1MrQmzrGW X-Gm-Message-State: ALoCoQn4+zF76glrPX1uMldFdYeY1yah0lt8OZgPUf7KgkitX7Hhnbgum3w7A6lDvLq88eQ5Abl9 X-Received: by 10.180.186.36 with SMTP id fh4mr5473415wic.7.1438009952944; Mon, 27 Jul 2015 08:12:32 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.5.67 with SMTP id q3ls618707laq.78.gmail; Mon, 27 Jul 2015 08:12:29 -0700 (PDT) X-Received: by 10.152.43.37 with SMTP id t5mr27071530lal.96.1438009949863; Mon, 27 Jul 2015 08:12:29 -0700 (PDT) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id 6si15497400lai.40.2015.07.27.08.12.29 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 27 Jul 2015 08:12:29 -0700 (PDT) Received-SPF: pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZJk4h-0005OC-8E for std-proposals@isocpp.org; Mon, 27 Jul 2015 17:12:19 +0200 Original-Received: from tripoint.kitware.com ([66.194.253.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Jul 2015 17:12:19 +0200 Original-Received: from mwoehlke.floss by tripoint.kitware.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Jul 2015 17:12:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 62 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: tripoint.kitware.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: X-Original-Sender: mwoehlke.floss@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) smtp.mail=gclcip-std-proposals@m.gmane.org; dmarc=fail (p=NONE dis=NONE) header.from=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:19317 Archived-At: On 2015-07-24 09:10, Vlad from Moscow wrote: > The C++ Standard already has all needed to do the task. And if you have a > pair of iterators that make up a range then why do you need to build a > range from already existent valid range?! Simply write > > for ( auto x : p ) ...; ....because you have stated that 'p' is a std::pair, i.e. a generic container type (albeit of exactly two elements). Range-based for on a container iterates over the elements in that container. It does NOT magically reinterpret the container according to some arbitrary assumed semantics. If you want a range, give a range. Don't give "something that kinda sorta maybe might look a little like a range if you tilt your head sideways and squint". > There is such principle KISS in programming that means Keep It Simple > Stupid. There is also the Principle of Least Surprise. Your proposal gratuitously violates it. I don't see that any of your examples are valid. Your examples where you used make_pair are clearly wrong; you meant to use make_range. Your minmax_element example is highly dubious; the return of said function is not semantically a range, and the contortions you go through to make it such ought to be telling you that you're doing something that's not intended use. (And equal_range clearly should be returning a range... that might be interesting to fix, but fixing it is the right thing to do. Not abusing std::pair.) On 2015-07-25 10:10, Vlad from Moscow wrote: > You can write any class that will provide begin and end and these begin and > end will not make up a range. I think you are reading more into the idea of "range" than is intended. A "range" is a valid, bounded iteration sequence. Nothing more. In particular, it does not necessarily have any relation to container iterators. The IP subnet 192.168.0.0/24 is a "range". More generally, I would say that any iterator pair where the iterators are equal (empty range) or incrementing from the first iterator will eventually arrive at the second iterator without at any point going off into la la land (valid range) is a "range". This does not precisely mean that a "range" *is* an iterator pair, although being iterable implies that one can always *get* an iterator pair from a range. Keep in mind also that the notion of "iterator" is quite broad, e.g. checking for equality to the "end" iterator may mean checking the dereferenced iterator against a sentinel value. If, given that definition, some class has begin() and end() that do NOT form a range, then that class is badly designed. Most would say "broken". > Standard containers and standard algorithms already use std::pair to > specify a valid range. ....which, per above, is a problem that should be fixed, not made worse by compounding the mistake. -- Matthew -- --- 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/. .