220 29008 article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Is World's Dumbest Pointer still on the table?!? Date: Thu, 20 Oct 2016 04:06:38 -0700 (PDT) Lines: 184 Approved: news@gmane.org Message-ID: References: <8a6731f7-1c9b-482d-817e-c2374fc9ae1b@isocpp.org> <7d817482-e7c3-4724-9501-738d4c9083d7@isocpp.org> <986ffd0c-7466-476a-96af-525aaf8b24ea@isocpp.org> <5adf05e5-edb4-4706-816b-59b71d5c1a6f@isocpp.org> <3241f484-0d5a-4363-8ddd-d3813a54fcb1@isocpp.org> <0c7c0968-f1c2-46df-b787-631fdd9f2d6c@isocpp.org> <39f69270-f3f8-412c-82ac-f192d2642185@isocpp.org> <21f90a12-3d1f-4f65-8974-66ee3a17f88d@isocpp.org> <6ddbccaf-a7eb-4193-86d0-31300fd2f9ae@isocpp.org> <8c24951b-5d86-46e4-85c8-1a9372020dff@isocpp.org> <2df66fdb-3586-4ccc-b589-558298b28a56@isocpp.org> <10dd3035-5546-414c-980f-2a1b06b9dd5b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_130_209579376.1476961598228" X-Trace: blaine.gmane.org 1476961639 13684 195.159.176.226 (20 Oct 2016 11:07:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 20 Oct 2016 11:07:19 +0000 (UTC) Cc: mihailnajdenov@gmail.com, joseph.thomson@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBP6KULAAKGQEVCO5NHI@isocpp.org Thu Oct 20 13:07:11 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f72.google.com ([209.85.213.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bxBBK-0007ea-AO for gclcip-std-proposals@m.gmane.org; Thu, 20 Oct 2016 13:06:42 +0200 Original-Received: by mail-vk0-f72.google.com with SMTP id q126sf43067324vkd.4 for ; Thu, 20 Oct 2016 04:06:44 -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:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=VzsOlrXbGPuyYEOXmQvQ6qlNtLV1eZ01KTq0pYLQbbk=; b=VIiAvSVYip3j5HgWTjy8Wm13xgts6IbcSK8D7zOOyb+wS4CypcEG77mAomJvuJO4N1 /aCfhvY9S7ZJaIO7z2IfEMt7s1Vp0XIFWR5JKPApOxpvSeBlBd1JcMH3vxTw3JJ77+BA Npcc9ik9SMcFHpB9LyzxOBJGfofttCdIMbB1KKG94vJfr0DXGwxx7ReDZclqRbFxEj32 nGXaSPX0BK0pgcTBV/0ola6nuhE19fH/ftymeZWS5AdVcAbBczDpNoNCdMaNtNhoapOK zKu+tzo0d+6kbymx7HG6S250lkdTmmqOepCmBEQJtO8r7UFwaT3amGXunOgMv+riVPVy 6zdg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=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=VzsOlrXbGPuyYEOXmQvQ6qlNtLV1eZ01KTq0pYLQbbk=; b=J5OA2tsIctvizBWt2WDF/WPCl4iOm5WQwVHot8PcrwcFKo7Q5spNgawS6VhoTSpKEr FaPRGYelfmDqmX4pmMg+pxV+GaGZkJooCToMnAXjLcPJY7nE3eqXIXNiZ0IG0Lz9ZkxO Q/6NGEDyY6p4JsZT7v5DdwpUA+0swxr6Gv/cCnoiK9vC+1OeWyijdpd9YuCnPHnHBouG CtszN5BYVagrJ4FdQ8xHWAONdjD0J4TizJbzc/0nlBjBUCYXdYIrDXfSmi37cv4BChEz cT2UM+yhRIccaWJWiI7nqWY56tbHAzYJjTWF9nZgin1561x0rlti/X9FU8ozWh/ydEmT r3dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=VzsOlrXbGPuyYEOXmQvQ6qlNtLV1eZ01KTq0pYLQbbk=; b=FoMLeHOgPbdLNHe0y35cpTrcb9xtD0o7PrGsROMoDbq8dsGr8PnwM7vgy8nwubeeFY KrnG76IO7+MFuXg0m3eucAznFad9IOgceicQsrFh8rKQ0XbSYqN9ZynTvPFsdBDz5OpV 1tFgUS8wrfVsUZFHjewoI33eLc++C13hAd84dvhqR/IJEhLqYMIIog46XDIQTgWOpJId 7TIeHa06yq7jCPi6TiwcOKNS74UvgVn94dBXj5sFhUvpV38yjZwF00pHzxnEx13qmfLZ 6K9EX9mMRfpOLyO/e/g8YvkiLccQLaw1CHegi6OPi1trilmwyhyanPSgbvqlYnzRtAJb k4XA== X-Gm-Message-State: AA6/9Rl23K6EZ14PRJiOwxIA0HHDsnz9JEspa6fEDKPPF/kNsp11tmFTl2oKYuNiMJ3+Ng== X-Received: by 10.31.82.69 with SMTP id g66mr3503909vkb.24.1476961604455; Thu, 20 Oct 2016 04:06:44 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.165.141 with SMTP id o135ls1486768ioe.44.gmail; Thu, 20 Oct 2016 04:06:39 -0700 (PDT) X-Received: by 10.36.71.141 with SMTP id t135mr948166itb.10.1476961599772; Thu, 20 Oct 2016 04:06:39 -0700 (PDT) In-Reply-To: <10dd3035-5546-414c-980f-2a1b06b9dd5b@isocpp.org> X-Original-Sender: MihailNajdenov@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:29008 Archived-At: ------=_Part_130_209579376.1476961598228 Content-Type: multipart/alternative; boundary="----=_Part_131_49941150.1476961598228" ------=_Part_131_49941150.1476961598228 Content-Type: text/plain; charset=UTF-8 On Thursday, October 20, 2016 at 11:45:10 AM UTC+3, joseph....@gmail.com wrote: > > On Thursday, 20 October 2016 15:09:16 UTC+8, mihailn...@gmail.com wrote: >> >> My intentions are not to change your mind - we, as well as everyone else, >> are perfectly aware of the pros and cons of both approaches - raw vs new >> ptr. >> > > I think it helps to have these things written down. Even if everyone else > knows everything already, it helps me get my thoughts in order and realize > where my reasoning is flawed. > Agreed. These pros and cons lists are important, so one can see all sides. I for one see better now, why people want a view type, most importantly - what features they want from it! > > We also agree, any "operator." (in quotes, not necessarily overloading it) >> will dramatically change any possible implementation of such a wrapper >> pointer type. >> > > I don't agree with this. I think "operator dot overloading" will have > limited to no application in this case. I believe it will have more of an > application with types that act to modify select parts of an API while > retaining the overall appearance of the underlying type like, for example, > propagate_const. > Considering all proposals include an impl of a smart reference - it certainly will have significant impact. We probably don't want to end up with too much observing wrappers. And lets be honest, references now are the non-null pointers we are trying to invent anew. They are invented for this same purpose ages ago. IF the downsides of these are solved (a.k.a. smart references), maybe they are the right way to handle the observer case. May be the future is not a pointer type, but a reference type. After all, they were the first observers out there! > > >> I also agree with you propagate_const should be integral part of such a >> wrapper pointer type, not a cumbersome opt-in. >> > > I'm in two minds about this. It may be better to keep const propagation > separate. > But we more often need the pointed-to be const, not the pointer. We write const auto* many times more often then auto*const. Yes, propagate, will mean const auto*const, so there should be control. In any case, propagation is not unreasonable default: It will enable const auto obj = getObj(); to mean what the user probably intended to mean! Vary, very reasonable default. It is interesting to note, smart references will suffer from the same problem. > As a result, I (still) strongly believe observer_ptr should *not* go into >> the standard in its current form. >> It will be half-assessed, and will rise as many issues/questions as it >> solves and will be become the auto_ptr version of a much better view type. >> > > Agreed. > -- 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/f4cf845d-638b-488b-afad-a6de0ab9addd%40isocpp.org. ------=_Part_131_49941150.1476961598228 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thursday, October 20, 2016 at 11:45:10 AM UTC+3= , joseph....@gmail.com wrote:
<= div dir=3D"ltr">On Thursday, 20 October 2016 15:09:16 UTC+8, mihailn...@= gmail.com wrote:
My intentions are not to change your mind=C2=A0- we, as well as eve= ryone else, are perfectly aware of the=C2=A0pros and cons of both approache= s - raw vs new ptr.
=C2=A0
I think it helps= to have these things written down. Even if everyone else knows everything = already, it helps me get my thoughts in order and realize where my reasonin= g is flawed.

Agreed. These = pros and cons lists are important, so one can see all sides. I for one see = better now,=C2=A0why people want a view type, most importantly - what featu= res they want from it!
=C2=A0

We also agree, any "opera= tor." (in quotes, not necessarily overloading it) will dramatically ch= ange any possible implementation of=C2=A0such a wrapper pointer type.
=

I don't agree with this. I think "oper= ator dot overloading" will have limited to no application in this case= .. I believe it will have more of an application with types that act to modi= fy select parts of an API while retaining the overall appearance of the und= erlying type like, for example, propagate_const.

<= div>Considering all proposals include an impl of a smart reference - it cer= tainly will have significant impact. We probably don't want to end up w= ith too much observing wrappers.


A= nd lets be honest, references now are the non-null pointers we are trying t= o invent anew. They are invented for this same purpose ages ago.
=
IF the downsides of these are solved (a.k.a. smart reference= s), maybe they are the right way to handle the observer case.
May be the future is not a pointer type, but a reference type.<= /div>
After all, they were the first observers out there!
=C2= =A0
=C2=A0
= I also=C2=A0agree with you=C2=A0propagate_const should be integral part of = such a wrapper pointer type, not a cumbersome opt-in.=C2=A0

I'm in two minds about this. It may be better to keep= const propagation separate.

But we more often need the pointed-to be const, not the pointer.
We write const auto* many times more often then auto*const= ..

Yes, propagate, will mean const auto*const, so t= here should be control.

In any case, propagation i= s not unreasonable default:

It will enable const a= uto obj =3D getObj();=C2=A0to mean what the user probably intended to mean!=
Vary, very reasonable default.

It is i= nteresting to note, smart references will suffer from the same problem.


As a result, I (still)=C2=A0strongly believe=C2=A0observer_ptr=C2=A0should= not=C2=A0go into the standard in its current form.
It will be h= alf-assessed, and will rise as many issues/questions as it solves and will = be become=C2=A0the=C2=A0auto_ptr version of a much better view type.
=

Agreed.

--
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/f4cf845d-638b-488b-afad-a6de0ab9addd= %40isocpp.org.
------=_Part_131_49941150.1476961598228-- ------=_Part_130_209579376.1476961598228-- .