220 19244 <9c360e55-9315-4585-9402-a813a4765e8d@isocpp.org> article Path: news.gmane.org!not-for-mail From: inkwizytoryankes@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Overloading std::begin and std::end for std::pair Date: Fri, 24 Jul 2015 11:59:16 -0700 (PDT) Lines: 529 Approved: news@gmane.org Message-ID: <9c360e55-9315-4585-9402-a813a4765e8d@isocpp.org> 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: multipart/mixed; boundary="----=_Part_439_767270575.1437764356352" X-Trace: ger.gmane.org 1437764374 14644 80.91.229.3 (24 Jul 2015 18:59:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jul 2015 18:59:34 +0000 (UTC) Cc: sasha2048@gmail.com, vlad.moscow@mail.ru To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDDLTAGNTIBBBBMWZKWQKGQEISR7FDY@isocpp.org Fri Jul 24 20:59:21 2015 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 1ZIiBj-0006o5-BB for gclcip-std-proposals@m.gmane.org; Fri, 24 Jul 2015 20:59:19 +0200 Original-Received: by igbqa2 with SMTP id qa2sf44830796igb.0 for ; Fri, 24 Jul 2015 11:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=qAQvrviRvYll/f1zytYC/zounj3Q3QFcjSCiVG50wr0=; b=bCH7cL7DrCuEL2Cc2rbjNnCnbDuXSbu1DCq/sIC5yi+9mQntWlincLYtwTRiNBZ8b1 dMqXR3LMTev7lJZDGlCiOXzA7zvoUGrSNdSkpIv5EihtPQFS5m7vPoEFhorcUb1SPVPn w7LOr/PE7c6TAN1z5svdHj4hExQ0VzVEIVCCgM7UPxS5UZQYeUx/EddqHcRPEGPCXaUB 0f2eB6omdnGGHgudbc+qp/jGl/7uEjCYY9rHaOfFanbARTKBu+DH80IXgN1UPqdT43g/ sX3kIQf0oF4m61qco7s18WJuRZ73QD2sJlC6MJ+LxwfQrB/XfOlE1NyFZ0SdMNkF4VsR J1zw== 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:cc:message-id:in-reply-to :references:subject:mime-version:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=qAQvrviRvYll/f1zytYC/zounj3Q3QFcjSCiVG50wr0=; b=TT4gp7AY5Y+/bfFUW+oHTLLKVuEWaGFle8E4J1Us20gwFZ8lXtfM3fqAGV1xQERLLJ vb6E694CQ4A5iu56NVC/W9e/EzFv9ayzOVBxwQFdJ1faOB9zHjxvzQQJvWeFcsSBsUQB UrRcfTk1x+AusD4d9x8RXR9GonGcMaTV6O19+dlvlWkt6VlJ7lAn2USvPBy6u8YnTSpD d1Q4LHjbaVNfLoa+itmUPBJ56h0QPqWlNzqmE9Lo2EKKfatzVEjFXj0i9c4vBmNL6goi ZgflQPfZGRbvKItGKMWOuyyIjoZF8k8HPAadWLuokpfTWOsub5MqSmU/yasA9aOvjpI6 G8lQ== X-Gm-Message-State: ALoCoQkZ0NmDtSnwXuZQtDl4zKNk346LKPebxpoZnAD96ncVD0vCccpw54/CfRo8JBbZ7YoSsGsG X-Received: by 10.107.157.76 with SMTP id g73mr14209622ioe.32.1437764358292; Fri, 24 Jul 2015 11:59:18 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.99.36 with SMTP id p33ls1622628qge.51.gmail; Fri, 24 Jul 2015 11:59:17 -0700 (PDT) X-Received: by 10.140.33.199 with SMTP id j65mr325934qgj.31.1437764357175; Fri, 24 Jul 2015 11:59:17 -0700 (PDT) In-Reply-To: X-Original-Sender: inkwizytoryankes@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:19244 Archived-At: ------=_Part_439_767270575.1437764356352 Content-Type: multipart/alternative; boundary="----=_Part_440_2084545534.1437764356354" ------=_Part_440_2084545534.1437764356354 Content-Type: text/plain; charset=UTF-8 If some object have `begin` and `end` then its range. Most pair aren't ranges then they should not have this functions. If some objects don't give you guarantees about something but you know in some cases it true then proper way of use is EXPLICITLY show that it hold true. In our case `std::make_range` fulfill this requirements. Probably solution for this problem are tagged pairs and tuples (IIRC they are form range proposition). It look something like that: extern int tab[10]; std::pair, std::end_tag> a; std::pair, std::success_tag> b; a.begin() = tab; //equal a.first = tab; a.end() = tab + 10; //equal a.second = tab + 10; for (auto& x : a) { if (x == 5) { b.ptr() = &x; b.success() = true; } } return b; On Friday, July 24, 2015 at 3:10:03 PM UTC+2, Vlad from Moscow wrote: > > > > On Friday, July 24, 2015 at 3:50:58 PM UTC+3, Sasha Unknown wrote: >> >> To T. C. and Sean Middleditch: Thank you for you patience. While I >> don't like the this proposal of Vlad from Moscow for many reasons, I >> appreciate patience and level of detail in your responses. At some >> point in future these patience and detail-level may save some good but >> ugly-looking proposal. >> >> To Vlad from Moscow: >> 1. Just to satisfy my interest: Aren't you coming to C++ from some >> dynamically-typed language? >> 2. If n2995 and/or D4128 would be accepted, they will satisfy all your >> requests: >> for ( auto x : std::make_range( a + 3, a + 7 ) ) ...; >> for ( auto p : m.equal_range( 'A' ) ) ...; >> >> > It seems you do not understand. There is no any need to build a > superconstruction or to deform algorithms that to do this in clear and > natural way. > > 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 ) ...; > > There is such principle KISS in programming that means Keep It Simple > Stupid. > > The programmer should not pay for what he totally need not. > > What you are suggesting looks the following way. I have a notebook. You > come to my home take away my notebook and say: "Pay me and i will give you > a notebook". And after I paid you return me my notebook. > > Excelent idea! > > > > > On Fri, Jul 24, 2015 at 10:36 AM, Vlad from Moscow >> wrote: >> > >> > >> > On Friday, July 24, 2015 at 1:58:22 AM UTC+3, Thiago Macieira wrote: >> >> >> >> On Thursday 23 July 2015 12:31:59 Vlad from Moscow wrote: >> >> > Could you explain why do I need some ranges when this program looks >> >> > clear >> >> > and nice without any ranges? >> >> >> >> Because you made it so that std::pair is always a range, but >> that >> >> isn't >> >> the case. In fact, I'd argue that most people who think of "iterating" >> >> over a >> >> pair expect it to behave as an array of two elements: the first and >> the >> >> second. >> >> >> > >> > There is a serious logical mistake. If for example two pointers can >> make up >> > a range this does not mean that any two pointers is a range or that any >> > range is two pointers. Even two iterators of the same container or two >> > pointers of the same array might not make a range. >> > >> > std::pair is simply a media that can store iterators. It is used in >> > algorithm std::mismatch where iterators does not make up a range or in >> the >> > algorithm or class methods equal_range where pointers make up a range. >> > >> > It is a responsibility of the programmer to use appropriate iterators >> that >> > are stored in the media. >> > >> > So you and Sean Middleditch attempts to substitute the meaning of >> std::pair >> > for the role like just ranges are false and confuse programmers. >> > It is responsibility of the programmer to correctly use std::pair in >> > different situations. >> > >> > With the same success you can use any valid C++ construction >> incorrectly. >> > For example you can return a reference to a local variable of a >> function. >> > Does it mean that something wrong with references and the programmers >> shall >> > not declare function return types as references? >> > >> > According to your false logic it follows that the programmers indeed >> shall >> > not declare function return types as references >> > >> > The ptoblem is why should the programmer pay for the means that he >> totally >> > need not? >> > >> > I showed already an example with std::multimap where the code looks >> clear >> > and nice. But you are saying: "Stop! Programs must not be so clear and >> nice. >> > You have to declare a class hierarchy and use these additional classes >> to do >> > a simple and entirely correct thing." >> > >> > Why do the programmer have to use a suoerstructure when he already has >> a >> > range that he stored on such a media like std::pair? >> > >> > And moreover now Sean Middleditch is even going to deform standard >> > algorithms with the only purpose that all programmers used his useless >> > superstructures where all can be done simply and clear without them. >> > >> > >> >> I'd expect: >> >> >> >> template const T* begin(const pair &p) >> >> { return &p.first; } >> >> >> >> template const T *end(const pair &p) >> >> { return &p.second + 1; } >> >> >> >> Which allows me to run: >> >> >> >> int main() >> >> { >> >> for (auto i : std::make_pair(1, 2)) >> >> cout << i << ' '; >> >> cout << endl; >> >> } >> >> >> >> output: 1 2 >> >> -- >> >> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org >> >> Software Architect - Intel Open Source Technology Center >> >> PGP/GPG: 0x6EF45358; fingerprint: >> >> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 >> >> >> > -- >> > >> > --- >> > 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-proposal...@isocpp.org. >> > To post to this group, send email to std-pr...@isocpp.org. >> > Visit this group at >> > http://groups.google.com/a/isocpp.org/group/std-proposals/. >> > -- --- 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_440_2084545534.1437764356354 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If some object have `begin` and `end` then its range. Most= pair aren't ranges then they should not have this functions.
If som= e objects don't give you guarantees about something but you know in som= e cases it true then proper way of use is EXPLICITLY show that it hold true= ..
In our case `std::make_range` fulfill this requirements.

Probab= ly solution for this problem are tagged pairs and tuples (IIRC they are for= m range proposition).
It look something like that:

extern int tab[10];=

st= d::= pair<std::begin_tag<int*>, std::= end_tag<= ;int*>>= a;
std::pair<std::ptr_tag= <int*>,= std::success_tag<bool>> b;

a.begin() =3D tab; //equal a.first =3D tab;
a.end() =3D tab + 10; //equal a.second =3D tab + 10;
for (auto& x : a<= /span>)
{
=C2=A0 =C2=A0 if (x =3D=3D 5)
=C2=A0 =C2= =A0 {
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 b.= ptr() =3D &x;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b.success() =3D= true;
=C2=A0 =C2=A0 }
}
return b;




On Friday, July= 24, 2015 at 3:10:03 PM UTC+2, Vlad from Moscow wrote:


On Friday, July 24, 2015 a= t 3:50:58 PM UTC+3, Sasha Unknown wrote:
To T. C. and Sean = Middleditch: Thank you for you patience. While I
don't like the this proposal of Vlad from Moscow for many reasons, = I
appreciate patience and level of detail in your responses. At some
point in future these patience and detail-level may save some good but
ugly-looking proposal.

To Vlad from Moscow:
1. Just to satisfy my interest: Aren't you coming to C++ from some
dynamically-typed language?
2. If n2995 and/or D4128 would be accepted, they will satisfy all your = requests:
=C2=A0 =C2=A0 for ( auto x : std::make_range( a + 3, a + 7 ) ) ...;
=C2=A0 =C2=A0 for ( auto p : m.equal_range( 'A' ) ) ...;


It seems you do not understand. There = is no any need to=C2=A0build a superconstruction or to deform algorithms th= at to do this in clear and natural way.

The C++ St= andard already has all=C2=A0needed to do the task.=C2=A0 And if you have a = pair of iterators that make up a range then why do you need to build a rang= e from already existent valid range?! Simply write

=C2=A0=C2=A0=C2=A0 for ( auto=C2=A0x :=C2=A0p ) ...;

=
There is such principle KISS in programming that means Keep It Simple = Stupid.

The=C2=A0programmer should not pay for wha= t he totally need not.

What you are suggesting loo= ks the following way. I have a notebook. You come to my home take away my n= otebook and say: "Pay me and i will give you a notebook". And aft= er I paid you=C2=A0return me my notebook.

Excelent= idea!




On Fri, Jul 24, 2015 at 10:36 AM, Vlad from Moscow <vlad....@mail.ru> wrote:
>
>
> On Friday, July 24, 2015 at 1:58:22 AM UTC+3, Thiago Macieira wrot= e:
>>
>> On Thursday 23 July 2015 12:31:59 Vlad from Moscow wrote:
>> > Could you explain why do I need some ranges when this pro= gram looks
>> > clear
>> > and nice without any ranges?
>>
>> Because you made it so that std::pair<T, T> is always a = range, but that
>> isn't
>> the case. In fact, I'd argue that most people who think of= "iterating"
>> over a
>> pair expect it to behave as an array of two elements: the firs= t and the
>> second.
>>
>
> There is a serious logical mistake. If for example two pointers ca= n make up
> a range this does not mean that any two pointers is a range or tha= t any
> range is two pointers. Even two iterators of the same container or= two
> pointers of the same array might not make a range.
>
> std::pair is simply a media that can store iterators. It is used i= n
> algorithm std::mismatch where iterators does not make up a range o= r in the
> algorithm or class methods =C2=A0equal_range where pointers make u= p a range.
>
> It is a responsibility of the programmer to use appropriate iterat= ors that
> are stored in the media.
>
> So you and Sean Middleditch attempts to substitute the meaning of = =C2=A0std::pair
> for the role like just ranges are false and confuse programmers.
> It is responsibility of the programmer to correctly use std::pair = in
> different situations.
>
> With the same success you can use any valid C++ construction incor= rectly.
> For example you can return a reference to a local variable of a fu= nction.
> Does it mean that something wrong with references and the programm= ers shall
> not declare function return types as references?
>
> According to your false logic it follows that the programmers inde= ed shall
> not declare function return types as references
>
> The ptoblem is why should the programmer pay for the means that he= totally
> need not?
>
> I showed already an example with std::multimap where the code look= s clear
> and nice. But you are saying: "Stop! Programs must not be so = clear and nice.
> You have to declare a class hierarchy and use these additional cla= sses to do
> a simple and entirely correct thing."
>
> Why do the programmer have to use a suoerstructure when he already= has a
> range that he stored on such a media like std::pair?
>
> And moreover now Sean Middleditch is even going to deform standard
> algorithms with the only purpose that all programmers used his use= less
> superstructures where all can be done simply and clear without the= m.
>
>
>> I'd expect:
>>
>> template<typename T> const T* begin(const pair<T, T&g= t; &p)
>> { return &p.first; }
>>
>> template<typename T> const T *end(const pair<T, T>= &p)
>> { return &p.second + 1; }
>>
>> Which allows me to run:
>>
>> int main()
>> {
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 for (auto i : std::make_pair(1, 2)= )
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cout &= lt;< i << ' ';
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 cout << endl;
>> }
>>
>> output: 1 2
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> =C2=A0 =C2=A0Software Architect - Intel Open Source Technology= Center
>> =C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
>> =C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 = F005 6EF4 5358
>>
> --
>
> ---
> 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-proposal...@isocpp.org.
> To post to this group, send email to std-pr...= @isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/= std-proposals/.

--

---
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_440_2084545534.1437764356354-- ------=_Part_439_767270575.1437764356352-- .