220 4701 article Path: news.gmane.org!not-for-mail From: Tony V E Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal to "fix" operator->* overloading Date: Wed, 29 May 2013 10:10:49 -0400 Lines: 118 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c365aae64a5f04dddbf298 X-Trace: ger.gmane.org 1369836652 26319 80.91.229.3 (29 May 2013 14:10:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 May 2013 14:10:52 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCUZ5QWKNQIOVGEYRUCRUBCUBUKSU@isocpp.org Wed May 29 16:10:52 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-we0-f199.google.com ([74.125.82.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Uhh5X-0006l2-Lq for gclcip-std-proposals@m.gmane.org; Wed, 29 May 2013 16:10:51 +0200 Original-Received: by mail-we0-f199.google.com with SMTP id p58sf7127273wes.2 for ; Wed, 29 May 2013 07:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:mime-version:in-reply-to:references:date:message-id :subject:from:to:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-google-group-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=mxjFNbcrcgEd/lAPQ5yrTUF/tNulxQhlOBh78g+3bpQ=; b=VQL3ATcRHHqBp7cmxVG3jw4MVUFVwWnJx2XjEzNAr+//dNS8tKXiZ/YvSGK1YSTAla +w6S6x3vayqR74m5ioUy4GnBfIMI+/SWQ+HPQMnKD/ifvg4MQw25T/4Qg4QEUvVF5bMd qYQhwvuu5K04AJrkrZHHmMOWAknosu7g7cTwl2pfZzAKShBdQOCHdm/Xd2iNmGLhbWTL cUn9A9r6zn2gTKmJJP1mypZpT3AoTE4K70e+eQcVa0zawwMLq0bUNBX939WxQRnVPXld rvk8PGxluUct1IQKt6ms9ASph813WB7991JmmTycf5hj003Rqa/iKFvf9WNuom8qb4QU Q2xg== X-Received: by 10.112.150.229 with SMTP id ul5mr256759lbb.18.1369836651115; Wed, 29 May 2013 07:10:51 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.6.39 with SMTP id x7ls229075lax.14.gmail; Wed, 29 May 2013 07:10:50 -0700 (PDT) X-Received: by 10.112.33.227 with SMTP id u3mr1727763lbi.35.1369836650046; Wed, 29 May 2013 07:10:50 -0700 (PDT) Original-Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by mx.google.com with ESMTPS id i1si6770289lbc.262.2013.05.29.07.10.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 May 2013 07:10:50 -0700 (PDT) Received-SPF: pass (google.com: domain of tvaneerd@gmail.com designates 209.85.217.180 as permitted sender) client-ip=209.85.217.180; Original-Received: by mail-lb0-f180.google.com with SMTP id r10so9123897lbi.11 for ; Wed, 29 May 2013 07:10:49 -0700 (PDT) X-Received: by 10.152.116.114 with SMTP id jv18mr1476289lab.15.1369836649596; Wed, 29 May 2013 07:10:49 -0700 (PDT) Original-Received: by 10.112.161.9 with HTTP; Wed, 29 May 2013 07:10:49 -0700 (PDT) In-Reply-To: X-Original-Sender: tvaneerd@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of tvaneerd@gmail.com designates 209.85.217.180 as permitted sender) smtp.mail=tvaneerd@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-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:4701 Archived-At: --001a11c365aae64a5f04dddbf298 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, May 29, 2013 at 4:12 AM, Daniel Kr=FCgler wrote: > 2013/5/29 Mikhail Semenov : > > Perhaps there is another solution, which requires the language change: > > (1) allow ->* overloading as it is at present; > > (2) but if -> is defined without ->* overloading, use -> class to get -= >* > > members. It looks strange that -> applies to members of one class, > > but ->* to another. (I know that they are different operators. It was > > probably a big mistake to allow ->* overloading in the first place, it > > should > > have followed ->). > > I don't think that the core language should impose such restrictions. > Coders can design classes with funny behavior, they can override unary > operator&, comma operator, etc. In many cases you won't do that, so > don't. What looks strange for you at the moment might be useful for > someone in another context. Why should we restrict them in doing so? > > Keep also in mind that the same kind of problems can occur for funny > smart pointers that override operator-> which does return something > inconsistent with operator*. I don't think that just by restricting > core language rules this would help to solve such problems. Think > further and you want that operator+=3D and operator+ are enforced to do > the equivalent things. Where do you want to stop? > > - Daniel > > We could, however, add some =3Ddefault magic (or whatever) that generates += =3D given +, and maybe ->* given ->, and the relational operators, etc. Tony --=20 ---=20 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 e= mail 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-proposa= ls/?hl=3Den. --001a11c365aae64a5f04dddbf298 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, May 29, 2013 at 4:12 AM, Daniel Kr=FCgler <daniel.= kruegler@gmail.com> wrote:
2013/5/29 Mikhail Semenov <mikhailsemenov1957@gmail.com>:
> Perhaps there is another solution, which requires th= e language change:
> (1) allow ->* overloading as it is at present;
> (2) but if -> is defined without ->* overloading, use -> clas= s to get ->*
> members. It looks strange that -> applies to members of one class,<= br> > but ->* to another. (I know that they are different operators. It w= as
> probably a big mistake to allow ->* overloading in the first place,= it
> should
> have followed ->).

I don't think that the core language should impose such restricti= ons.
Coders can design classes with funny behavior, they can override unary
operator&, comma operator, etc. In many cases you won't do that, so=
don't. What looks strange for you at the moment might be useful for
someone in another context. Why should we restrict them in doing so?

Keep also in mind that the same kind of problems can occur for funny
smart pointers that override operator-> which does return something
inconsistent with operator*. I don't think that just by restricting
core language rules this would help to solve such problems. Think
further and you want that operator+=3D and operator+ are enforced to do
the equivalent things. Where do you want to stop?

- Daniel


We could, however, add some =3Ddefault magic (o= r whatever) that generates +=3D given +, and maybe ->* given ->, and = the relational operators, etc.

Tony

=A0

--
 
---
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-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-pro= posals/?hl=3Den.
 
 
--001a11c365aae64a5f04dddbf298-- .