220 41562 article Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: wpmgprostotema@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: operator[]= (array subscript assignment operator) Date: Fri, 15 Mar 2019 16:42:05 -0700 (PDT) Approved: news@gmane.org Message-ID: References: <39460c2e-f24c-4819-8678-267387948e69@isocpp.org> <6a65b6a7-5fc2-415f-be8e-fbeaae76e20f@isocpp.org> Reply-To: std-proposals@isocpp.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_906_451464444.1552693326017" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="58329"; mail-complaints-to="usenet@blaine.gmane.org" Cc: wpmgprostotema@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDC4PXOG5IMRBT7QWDSAKGQEQ3KCKLA@isocpp.org Sat Mar 16 00:42:11 2019 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f72.google.com ([209.85.161.72]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1h4wSo-000F4V-9P for gclcip-std-proposals@m.gmane.org; Sat, 16 Mar 2019 00:42:10 +0100 Original-Received: by mail-yw1-f72.google.com with SMTP id d18sf13933431ywb.2 for ; Fri, 15 Mar 2019 16:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=qP9l8BqlaPMrbcHtA0ZRFvixJSlMy9fxG6FF5W2nU3w=; b=gxKaWbcERTrNqRkgvfrNqlgjcDSsIW1TDk4X7LDAem1eROjZFhTYbKYtODZtFilgvr ck1po6vib62Ga6iTdOxve3Q6blKRmpfHJg8mk9MnT4ul+2NDWNyaWhb2cMsoBVNIiomN TftAyN4HjchoAAlgyqgAyRwbF1VRsve3+vGLTj6M9e3wFY3sHGYoPJ1EmpjHDXJ45ium S7tGD+TisdGxfvEldCK7EY7H6aJyqgaCajERF+8KDmd6xXTHk1EE8NGXMTY866qdl08k fHhmQXxY0OTIUS0ebfH1TOHmgx6mFTpulVK66EZVcj0XVs4FCtLD6t0g2bNPk0UhA+pu Gybw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=qP9l8BqlaPMrbcHtA0ZRFvixJSlMy9fxG6FF5W2nU3w=; b=Qc7TcfwTR8mxap0af9Wcnj61dMrtg181p0FMa3ildaMwKp4DBwkfhVsBLIkD/uIwvx pKkQpgXRU2BR2wRbfcquJB5pVXRplGWRafqkI8iz7WebAHYhLOzfEK+rSykrYpYzF0XH GJi+O5KFLCM7pNyKpDg+cI4SQFZZu3f7sg0nJ/Al/OUUpHUh0KC6wlf+2P+daqxo1QHb RmG/TwpPd0+cnqS20Du7mxWuE+GybGFremdSrYoW9kn9qV1SGxgnRWSbNT+HKiz82jfT nh18zNnP7LGna1OmkLHU+MmXyOpfW3rRgKcgzXdm5kZKuetKbLF1Q8yO32rNehG5mics R88A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version: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=qP9l8BqlaPMrbcHtA0ZRFvixJSlMy9fxG6FF5W2nU3w=; b=M+m9eet4QHlPTjMHEcGMk3txdRLGnpZJr/KJqLPC/yrOWXXJHdYhW+Qgqw1EfDsZwo 6Idfogef20IJ3zDgfroUNDVbpnlbmP+4wCS24zgvAZvl4Bn7/awtsVz2to352q/PL2PX FhLRq1wfg2UyiOxNFHYLJddTb3AOD2l8zDsmqNSGWePH1XbbcCCVmJ44DVbECknTFapQ dmlZjoqJKFN8IRQcPagZXg84rZ9WBPkXsS+y2n161hX8nyK4G2fxZnk/fgr0fbhZpDce 1Gn9cn3FyevpfSZhBEcZi0/1FZJedeZ45L+iUzo2J+XwkxUpJQep6M/c/Ey6ax1YPyYw vtLA== X-Gm-Message-State: APjAAAUnf+vST3gycZT/c77SRqhiXcRmiN1h2wXYHtCctAU2bJf+43Fz u0Gy1OdwSaS3q8/QTsXI0TGiwQ== X-Google-Smtp-Source: APXvYqx+DqZwbBMHsuW3trgn4rUPzoM/bWY7ifiPxt/quxB7DqEojg1JSKFlQQYfskECyo6DjnvWYg== X-Received: by 2002:a81:3cd7:: with SMTP id j206mr2877098ywa.11.1552693328706; Fri, 15 Mar 2019 16:42:08 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:1384:: with SMTP id 126ls1978001ybt.1.gmail; Fri, 15 Mar 2019 16:42:06 -0700 (PDT) X-Received: by 2002:a25:6d46:: with SMTP id i67mr5447659ybc.384.1552693326654; Fri, 15 Mar 2019 16:42:06 -0700 (PDT) In-Reply-To: <6a65b6a7-5fc2-415f-be8e-fbeaae76e20f@isocpp.org> X-Original-Sender: wpmgprostotema@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:41562 Archived-At: ------=_Part_906_451464444.1552693326017 Content-Type: multipart/alternative; boundary="----=_Part_907_23573654.1552693326017" ------=_Part_907_23573654.1552693326017 Content-Type: text/plain; charset="UTF-8" > > Evaluation order for overloaded operators when defined works on the basis > of the appearance of the expressions in code, not on the order of the > parameters to the eventual function call. Assignment operators are ordered > right-to-left, even though you could consider the first parameter of the > member function to be `this` (ie: the left side). > > An `operator[]=` is an assignment operator; as such, it should order > things like other assignment operators: right-to-left. > Thanks for clarifying that. Here's something else that should be considered. This feature exists to > optimize a particular use case of something that is actually more general > in C++: access/assignment paring. That is, the user is conceptually > accessing an object, but they're doing it for the purpose of performing > assignment to the accessed object. > > The reason I suggest you consider this is that OutputIterators are > fundamentally based on this. One of the most annoying aspects of writing a > pure OutputIterator is that you have to kind of fudge the way its > `operator*` works. If you cannot manifest an actual `value_type` to assign > to, then you have to return a proxy object that references the meat of the > iterator, which then uses its assignment operator to do the actual > assignment. > > Avoiding that kind of thing would help make writing OutputIterators > something that normal C++ programmers can idiomatically understand and > implement. > > Your proposal would probably be stronger if it could solve this problem > too, to allow `*it = foo;` and `*it++ = foo;` to magically transform into a > single function call of the form `operator(foo)`. And that's not > going to be easy. > > Especially since the obvious `operator*=` is already taken ;) > Thanks for the nice suggestion! The only good idea about operator syntax that come to my mind is `operator*operator=` and more generally `operator$operator@` where $ can be * or [] and @ is one of =, +=, -=, *=, /=, %=, &=, |=, ^=, <<=, >>=, ++, --. `operator[]operator|=` and similar would fit good for `std::vector`/`std::bitset`-like containers and for their iterators. `std::map`/`std::unordered_map` `operator[]` can not be fixed for >> compatibility reasons > > > I see no reason why this would *have* to be the case. As long as > `some_map[key] = value` has the same behavior, it will be fine. After all, > you still need the regular `operator[]` overload to make values accessible. > > Can you come up with a scenario where calling the `operator[]=` overload > will have genuinely breaking behavior? Yes, it will call the copy/move > constructor rather than a default constructor & copy/move assignment. But > the rules of `map` already requires that these must be equivalent > operations, right? > I was talking primarily about current `operator[]` behavior for non-existing entries (creating entries with default-constructed values instead of throwing exceptions). But you are right, adding `operator[]=` (or `operator[]operator=`) overload for `std::map` should not break the current behavior. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eb376b4b-11ba-4bb3-af7a-378556166ea6%40isocpp.org. ------=_Part_907_23573654.1552693326017 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Evaluation order for overloaded operators when defined works = on the basis of the appearance of the expressions in code, not on the order= of the parameters to the eventual function call. Assignment operators are = ordered right-to-left, even though you could consider the first parameter o= f the member function to be `this` (ie: the left side).

An `operator[]=3D` is an assignment operator; as such, it should orde= r things like other assignment operators: right-to-left.
<= /blockquote>

Thanks for clarifying that.

<= /div>
Here's something else that should be considered. This feature exists = to optimize a particular use case of something that is actually more genera= l in C++: access/assignment paring. That is, the user is conceptually acces= sing an object, but they're doing it for the purpose of performing assi= gnment to the accessed object.

The reason I sugges= t you consider this is that OutputIterators are fundamentally based on this= .. One of the most annoying aspects of writing a pure OutputIterator is that= you have to kind of fudge the way its `operator*` works. If you cannot man= ifest an actual `value_type` to assign to, then you have to return a proxy = object that references the meat of the iterator, which then uses its assign= ment operator to do the actual assignment.

Avo= iding that kind of thing would help make writing OutputIterators something = that normal C++ programmers can idiomatically understand and implement.

Your proposal would probably be stronger if it could = solve this problem too, to allow `*it =3D foo;` and `*it++ =3D foo;` to mag= ically transform into a single function call of the form `operator<whate= ver>(foo)`. And that's not going to be easy.

Especially since the obvious `operator*=3D` is already taken ;)

Thanks for the nice suggestion! Th= e only good idea about operator syntax that come to my mind is `operator*op= erator=3D` and more generally `operator$operator@` where $ can be * or [] a= nd @ is one of =3D, +=3D, -=3D, *=3D, /=3D, %=3D, &=3D, |=3D, ^=3D, <= ;<=3D, >>=3D, ++, --. `operator[]operator|=3D` and similar would f= it good for `std::vector<bool>`/`std::bitset`-like containers and for= their iterators.

`std::map`/`std::unordered_map` `operator[]` can not be fixed for= compatibility reasons

I see no reason why = this would have to be the case. As long as `some_map[key] =3D value`= has the same behavior, it will be fine. After all, you still need the regu= lar `operator[]` overload to make values accessible.

Can you come up with a scenario where calling the `operator[]=3D` overlo= ad will have genuinely breaking behavior? Yes, it will call the copy/move c= onstructor rather than a default constructor & copy/move assignment. Bu= t the rules of `map` already requires that these must be equivalent operati= ons, right?

I was tal= king primarily about current `operator[]` behavior for non-existing entries= (creating entries with default-constructed values instead of throwing exce= ptions). But you are right, adding `operator[]=3D` (or `operator[]operator= =3D`) overload for `std::map` should not break the current behavior.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/eb376b4b-11ba-4bb3-af7a-378556166ea6= %40isocpp.org.
------=_Part_907_23573654.1552693326017-- ------=_Part_906_451464444.1552693326017-- .