220 4697 article Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal to "fix" operator->* overloading Date: Wed, 29 May 2013 10:12:42 +0200 Lines: 35 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: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1369815163 9543 80.91.229.3 (29 May 2013 08:12:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 May 2013 08:12:43 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCT7RVFA4QORB67QS2GQKGQEKMLZX3A@isocpp.org Wed May 29 10:12:44 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f199.google.com ([209.85.217.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UhbUy-00037J-3d for gclcip-std-proposals@m.gmane.org; Wed, 29 May 2013 10:12:44 +0200 Original-Received: by mail-lb0-f199.google.com with SMTP id x10sf6830469lbi.2 for ; Wed, 29 May 2013 01:12:43 -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=rwmrNxbMsRZYA1Ej4LITfnGxIVRaFuJynYNHEW9xrAg=; b=sSlgrj4r3PM16omFxhCByWmL0YGospFg4MOwFbq5C8RdzXSIs8NDzjWdo2PcGNggex oJEzC6XQbnetAsz5kgO8Zo7gjW5gEKtu2SHroFXAIOCN6UIaSWa0KJwk1XgeDu5cj1T1 SlIslWY8mx4xgM+i+JdOQte/82Y4FuZ+qBs/kqZaaQHBpze+bA6QpWjbU1vqXhd0hIhs 0CJYuFTJ7Qz3QA5G7OnuOZl2w/w+QHfXoW0Sinb8fEUIGEx/DQYrv38XhalZK75RPbzZ k6NM4fw+cscqCdz7wE2l8eG0YjM8DoyOte08xdJ3pFQ7Wr6D5hEugiOpjrP0PnAqi4wt eU7w== X-Received: by 10.180.206.107 with SMTP id ln11mr5819302wic.7.1369815163577; Wed, 29 May 2013 01:12:43 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.160.130 with SMTP id xk2ls1351624wib.15.gmail; Wed, 29 May 2013 01:12:42 -0700 (PDT) X-Received: by 10.194.82.161 with SMTP id j1mr1340850wjy.9.1369815162541; Wed, 29 May 2013 01:12:42 -0700 (PDT) Original-Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [2a00:1450:400c:c03::22c]) by mx.google.com with ESMTPS id gm7si7179131wib.39.2013.05.29.01.12.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 May 2013 01:12:42 -0700 (PDT) Received-SPF: pass (google.com: domain of daniel.kruegler@gmail.com designates 2a00:1450:400c:c03::22c as permitted sender) client-ip=2a00:1450:400c:c03::22c; Original-Received: by mail-we0-f172.google.com with SMTP id w62so6087015wes.31 for ; Wed, 29 May 2013 01:12:42 -0700 (PDT) X-Received: by 10.194.78.12 with SMTP id x12mr1300664wjw.28.1369815162359; Wed, 29 May 2013 01:12:42 -0700 (PDT) Original-Received: by 10.216.164.9 with HTTP; Wed, 29 May 2013 01:12:42 -0700 (PDT) In-Reply-To: X-Original-Sender: daniel.kruegler@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of daniel.kruegler@gmail.com designates 2a00:1450:400c:c03::22c as permitted sender) smtp.mail=daniel.kruegler@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:4697 Archived-At: 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+= and operator+ are enforced to do the equivalent things. Where do you want to stop? - Daniel -- --- 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/?hl=en. .