220 39466 <6d6c6199-44b5-4eff-93b1-4f878736972a@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: junekey91@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Allow use of "->" when operator* presents Date: Wed, 1 Aug 2018 01:39:45 -0700 (PDT) Lines: 121 Approved: news@gmane.org Message-ID: <6d6c6199-44b5-4eff-93b1-4f878736972a@isocpp.org> References: <53f13047-62e7-4b31-ab7d-f3134e15eb08@isocpp.org> <2a326be3-4a3d-466e-819f-56dbac65b620@isocpp.org> <17350bb9-f223-48b5-9d64-70173325e678@isocpp.org> <238e09a4-3978-417d-9ed8-1f59d9e3bccb@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_12457_1978032428.1533112786086" X-Trace: blaine.gmane.org 1533112662 29799 195.159.176.226 (1 Aug 2018 08:37:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Aug 2018 08:37:42 +0000 (UTC) Cc: junekey91@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD63NZENTENRBUXDQXNQKGQEYUW46MI@isocpp.org Wed Aug 01 10:37:37 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f197.google.com ([209.85.213.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fkmdV-0007fS-D9 for gclcip-std-proposals@m.gmane.org; Wed, 01 Aug 2018 10:37:37 +0200 Original-Received: by mail-yb0-f197.google.com with SMTP id n7-v6sf9615072ybo.1 for ; Wed, 01 Aug 2018 01:39:48 -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=QhhvNUF8hJZc47VL1uHmDt4zSa9fCrKMLm81ac9OaIs=; b=RFYCETjsSO9+4FJp7Te3nzN61uJS2qyrolt6BoQlVvfcNT8MTPPK3FET3P0XXBHZrX sIgdgY+7KeaYxCjN8IBiUXKdr6xJLyB9ipzXlTELlvM2UmCYhLgGdGN77lEq5zCRuOG6 cUEvCBBPXc6jCgQIxidHGl3fGlwtD/F1w+4FjCnK8NFfNW4sT3cj+rpNrjKZRwbv3RVI ptswawiY6Oby07Yc75T7i8nICyOazqY07sCLJFzsWjXj1Alz+qFtZ1SOB2t3daBy/41n MaQICmf4etKeA9RBbvcsBSb/pjm6gzimqmCj5D6d6CfnR9NwvI8QOtZ+i+UueufBp/g7 wdaw== 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=QhhvNUF8hJZc47VL1uHmDt4zSa9fCrKMLm81ac9OaIs=; b=XViYmRNWI37gC3Rkj+ndDi6SYq59ejyZpPqkEFNPk0RistL2+oZxbcyVu0pOIiwFXu U1jbvUt7x+1ZtjEZUv64NYKJ1KYV89QvdSeS6KTalucPs3MMCp06rj6BQBz/PJh5MJ5C cXYVzyTllrOmEmq2/u89WJA5vz0z852zuduq0ZOkHeZCW2DakOQcH6j6ty/QG6IKnaol KFRPZRmXl/Oevn8wE0gUhp6syxYEiyyLFuz5uAwSoIz0IOrjHXWKU7R7VyOJDBhHqQT9 q6xbwNGmGhqZdinxQHkUyYjxPpLEro7DHYobFCO1K2RVdyaHonBs9U0mYIxkFncQ3StY 7nBw== 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=QhhvNUF8hJZc47VL1uHmDt4zSa9fCrKMLm81ac9OaIs=; b=IS0ThLF91UuaTqkcJEN0DtHsoCX0NfcDjL6c5ixvXkKbQ/iIKaJeP9fCMjhztIpkuM pMtniQkkcdLHhjbzTAv4ax8ZTyB2b4CYMNMtxweHn+Xiipe6sYi89DcfnutGtruOplus Xsf86tXeKDAEZZTuyU5UCIBOjWdL2RyskpFYnzmXre7AOoKTps9hjElWIjdtrIiu4Dtb QMv12Fhqa5kWyae0wRNlakCxKguQlA5sfRKpFlxtWi3uptmd1y+JWLBKVaPZgWRf7Qfj MUGqgea0WxbiMG/fuMH/ejh1uJCjfMI2guSYao9f00O71miSjyUuNhP2E1uk3Jbq6Iuh 17YA== X-Gm-Message-State: AOUpUlFP4bj0vHD2Jc3HJNC1and0dbms6G6MUEzE+3PN9P9YPdqiBwsB wPJJEpRCN1Yr6nt3/vnk30+AOg== X-Google-Smtp-Source: AAOMgpdjp7f7NZkNOV/0TK9ypu7g6TtgOq1FIGuf9Xp4Qhu6U83qpAKxOmEfTZ09zH8aVl39ikwV3w== X-Received: by 2002:a0d:d144:: with SMTP id t65-v6mr7182708ywd.197.1533112787969; Wed, 01 Aug 2018 01:39:47 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:4706:: with SMTP id u6-v6ls2580936ywa.1.gmail; Wed, 01 Aug 2018 01:39:46 -0700 (PDT) X-Received: by 2002:a81:a611:: with SMTP id d17-v6mr404760ywh.2.1533112786650; Wed, 01 Aug 2018 01:39:46 -0700 (PDT) In-Reply-To: <238e09a4-3978-417d-9ed8-1f59d9e3bccb@isocpp.org> X-Original-Sender: junekey91@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:39466 Archived-At: ------=_Part_12457_1978032428.1533112786086 Content-Type: multipart/alternative; boundary="----=_Part_12458_1013542323.1533112786086" ------=_Part_12458_1013542323.1533112786086 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Actually, I've considered that (returning references). But can't that may= =20 break existing codes? For example, what if someone's operator-> returns a reference to=20 pointer-like subobject? If that pointer-like subobject is something like std::unique_ptr, we really= =20 can't return by value, so I expect those situations are indeed not very rare. About opt-in syntax: I like it. Perhaps we need to discuss about opt-in (=3Ddefault) vs opt-out= =20 (=3Ddelete)? On Wednesday, August 1, 2018 at 4:08:27 PM UTC+9, Alberto Barbati wrote: > > Il giorno mercoled=C3=AC 1 agosto 2018 08:35:29 UTC+2, Alberto Barbati ha= =20 > scritto: >> >> Il giorno marted=C3=AC 31 luglio 2018 08:58:01 UTC+2, june...@gmail.com = ha=20 >> scritto: >>> >>> >>> Also, I think "not saying anything about operator->" will not magically= =20 >>> guarantee things we normally expect about operator->, >>> because it is still possible that operator-> is overloaded. So in order= =20 >>> to provide proper guarantees, >>> it is still needed to check possible relations between operator* and=20 >>> operator->, so the problem you pointed out may arise again. >>> >> >> What about providing some opt-in syntax like >> >> auto operator->() =3D default; >> > > Or, better, we could allow operator->() to return either a pointer or a= =20 > reference and then interpret x->m as (x.operator->())->m or=20 > (x.operator->()).m respectively. > > --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/6d6c6199-44b5-4eff-93b1-4f878736972a%40isocpp.or= g. ------=_Part_12458_1013542323.1533112786086 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Actually, I've considered that (returning referen= ces). But can't that may break existing codes?
For example, w= hat if someone's operator-> returns a reference to pointer-like subo= bject?
If that pointer-like subobject is something like std::uniq= ue_ptr, we really can't return by value,
so I expect those si= tuations are indeed not very rare.

About opt-in sy= ntax:
I like it. Perhaps we need to discuss about opt-in (=3Ddefa= ult) vs opt-out (=3Ddelete)?



On Wednesday, Augu= st 1, 2018 at 4:08:27 PM UTC+9, Alberto Barbati wrote:
Il giorno mercoled=C3=AC 1 agosto = 2018 08:35:29 UTC+2, Alberto Barbati ha scritto:
Il giorno marted=C3=AC 31 luglio 2018 08:58:0= 1 UTC+2, june...@gmail.com ha scritto:

Also, I think "not saying anything= about operator->" will not magically guarantee things we normally = expect about operator->,
because it is still possible that= operator-> is overloaded. So in order to provide proper guarantees,
it is still needed to check possible relations between operator* and= operator->, so the problem you pointed out may arise again.
=

What about providing some opt-in syntax li= ke

=C2=A0=C2=A0 auto operator->() =3D default;<= /div>

Or, better, we could allow oper= ator->() to return either a pointer or a reference and then interpret x-= >m as (x.operator->())->m or (x.operator->()).m respectively.

--
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/6d6c6199-44b5-4eff-93b1-4f878736972a= %40isocpp.org.
------=_Part_12458_1013542323.1533112786086-- ------=_Part_12457_1978032428.1533112786086-- .