220 16076 article Path: news.gmane.org!not-for-mail From: mobi phil Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: const T* operator->() const Date: Sat, 7 Feb 2015 01:23:25 +0100 Lines: 160 Approved: news@gmane.org Message-ID: References: <56a7727d-9839-45c9-be72-a6ecb61f38c9@isocpp.org> <79072019.ttkhiFK88n@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b343c9ca9d305050e748bf5 X-Trace: ger.gmane.org 1423268609 4686 80.91.229.3 (7 Feb 2015 00:23:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Feb 2015 00:23:29 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDF3H34L74HRB7VV2WTAKGQEN6HEHHQ@isocpp.org Sat Feb 07 01:23:28 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f199.google.com ([209.85.160.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YJtBH-00028v-EU for gclcip-std-proposals@m.gmane.org; Sat, 07 Feb 2015 01:23:27 +0100 Original-Received: by mail-yk0-f199.google.com with SMTP id 10sf22354813ykt.2 for ; Fri, 06 Feb 2015 16:23:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=LUroaRDcqFvf3+TxMHzodtRzU6MNpD5DvHAsp6XgAOU=; b=Y7F0n7VKp4ecYctiCUNzaSfPX/VJEZaJ0uZTg168vLCM4IEvRUMgR8d3j02uD5Qv7S qcNkxAZsXMXO67RYnkWRlIP2Vc+GINEGKXtMcDd2EVNp6AlyrBQeQRWU8bNDuNSfVHAj Rk/kv2iy7ocaerfmSGh1h23jDXxj5dOANqZWBk+0cE2FFqUvFRp71iqlkHFIrPe7bdye IdrICbTVrRu5g28uAFL3qEnNoxuKqdUJin7jYCv+NdvHdIB3f/L+qDgTmYrUX87mGJpI VCIelWbbqEg22KxH+mDq+K0YKgW7KvIXvhGzKDd/ZpbsDswxcNLU6XwWDWcZNoouoXAd 7r2Q== X-Gm-Message-State: ALoCoQlmJUMtZ0lDkyHC9ac3KYt8WamvQ3kiXEoR6aR/QtXfRGuIMW6lvkbxudxWmOu3kH5qE2rH X-Received: by 10.236.208.65 with SMTP id p41mr5459370yho.42.1423268606677; Fri, 06 Feb 2015 16:23:26 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.33.115 with SMTP id q19ls378218igi.25.gmail; Fri, 06 Feb 2015 16:23:25 -0800 (PST) X-Received: by 10.42.152.197 with SMTP id j5mr15405463icw.40.1423268605923; Fri, 06 Feb 2015 16:23:25 -0800 (PST) Original-Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com. [209.85.213.180]) by mx.google.com with ESMTPS id i200si3002450ioi.11.2015.02.06.16.23.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Feb 2015 16:23:25 -0800 (PST) Received-SPF: none (google.com: mobi@mobiphil.com does not designate permitted sender hosts) client-ip=209.85.213.180; Original-Received: by mail-ig0-f180.google.com with SMTP id b16so6382025igk.1 for ; Fri, 06 Feb 2015 16:23:25 -0800 (PST) X-Received: by 10.50.129.9 with SMTP id ns9mr4989171igb.24.1423268605703; Fri, 06 Feb 2015 16:23:25 -0800 (PST) Original-Received: by 10.50.186.167 with HTTP; Fri, 6 Feb 2015 16:23:25 -0800 (PST) In-Reply-To: <79072019.ttkhiFK88n@tjmaciei-mobl4> X-Original-Sender: mobi@mobiphil.com X-Original-Authentication-Results: mx.google.com; spf=none (google.com: mobi@mobiphil.com does not designate permitted sender hosts) smtp.mail=mobi@mobiphil.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:16076 Archived-At: --047d7b343c9ca9d305050e748bf5 Content-Type: text/plain; charset=UTF-8 > > > (As I understand, your original objective is to be able to automagically > > choose between a detaching and non-detaching operator-> based on the RHS > > of the '->'. We can't do that currently, so the only 'correct' way I can > > think of to make your Cow class "work correctly" is to force the user to > > specify. As I understand it, your objective is to improve that > situation.) > > And the discussion derailed when I stated that RHS isn't enough for what > the > OP wanted in the end: you can't tell whether the non-const RHS will be > used in > a const context. When there are const and non-const overloads available, > the > compiler will always choose the non-const one for a non-const object (cf. > "begin" functions in the containers). > > In other words, if I write: > > for (auto it = container->begin(); it != container->end(); ++it) > ; > > I might be calling the non-const begin() and end(), which will cause a > detach, > even though I never actually modify the container. > > If you wanted to avoid the detach, you'd have to write: > > for (auto it = container->cbegin(); it != container->cend(); ++it) > > But if you've done that, then it's unnecessary to have operator-> do the > work. > The work can reside in begin() and end(). > > In my opinion, this request adds too little new benefit to be worth it. > Dear Thiago, while Matthew Woehlke for instance correctly understood my point, you still fail to see that I correctly understand how the compiler interprets the story. It was just an observation that if the compiler would be able to reason in the context of the "->" operator (or for the sake of avoiding confusion lets call it "$#A#$$!" operator ) about the right side, constructs that I mentioned would be possible. Unfortunately there are not so many operators available, and the language is not ready to allow the implementation of such a construct. While you fail to see this and you are still thinking in terms of current implementation of the "->" operator, you conclusion of too "little benefit" is so far without any support. If you did not understand the problem fully please refrain to draw the conclusion that it adds too little benefit. At the end of the day I would not care if this would be o function, what i care is to have the mechanism to reason about the type of member methods/functions. As Ville Voutilainen mentioned, probably such a story would be possible to implement using the proposed reflection framework, or with my yet another non-sense proposal about "generalized templates" or "compile time C++". -- --- 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/. --047d7b343c9ca9d305050e748bf5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> (As I understand, your original objectiv= e is to be able to automagically
> choose between a detaching and non-detaching operator-> based on th= e RHS
> of the '->'. We can't do that currently, so the only &#= 39;correct' way I can
> think of to make your Cow class "work correctly" is to force= the user to
> specify. As I understand it, your objective is to improve that situati= on.)

And the discussion derailed when I stated that RHS isn't enough = for what the
OP wanted in the end: you can't tell whether the non-const RHS will be = used in
a const context. When there are const and non-const overloads available, th= e
compiler will always choose the non-const one for a non-const object (cf. "begin" functions in the containers).

In other words, if I write:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 for (auto it =3D container->begin(); it !=3D= container->end(); ++it)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;

I might be calling the non-const begin() and end(), which will cause a deta= ch,
even though I never actually modify the container.

If you wanted to avoid the detach, you'd have to write:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 for (auto it =3D container->cbegin(); it != =3D container->cend(); ++it)

But if you've done that, then it's unnecessary to have operator->= ; do the work.
The work can reside in begin() and end().

In my opinion, this request adds too little new benefit to be worth it.
=

Dear Thiago,=C2=A0

while Matthew Woehlke for instance correctly understood my point, you sti= ll fail to see that I correctly understand how the compiler interprets the = story. It was just an observation that if the compiler would be able to rea= son in the context of the "->" operator (or for the sake of av= oiding confusion lets call it "$#A#$$!" operator ) about the righ= t side, constructs that I mentioned would be possible. Unfortunately there = are not so many operators available, and the language is not ready to allow= the implementation of such a construct. While you fail to see this and you= are still thinking in terms of current implementation of the "->&q= uot; operator, you conclusion of too "little benefit" is so far w= ithout any support. If you did not understand the problem fully please refr= ain to draw the conclusion that it adds too little benefit. At the end of t= he day I would not care if this would be o function, what i care is to have= the mechanism to reason about the type of member methods/functions. As=C2= =A0Ville Voutilainen mentioned, probably such a story would be possible to = implement using the proposed reflection framework, or with my yet another n= on-sense proposal about "generalized templates" or "compile = time C++".






<= table cellpadding=3D"0" class=3D"" style=3D"font-size:13px">
<= /div>

--

---
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>.
--047d7b343c9ca9d305050e748bf5-- .