220 28978 <21f90a12-3d1f-4f65-8974-66ee3a17f88d@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: joseph.thomson@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Is World's Dumbest Pointer still on the table?!? Date: Wed, 19 Oct 2016 10:05:07 -0700 (PDT) Lines: 225 Approved: news@gmane.org Message-ID: <21f90a12-3d1f-4f65-8974-66ee3a17f88d@isocpp.org> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_535_1231100927.1476896707571" X-Trace: blaine.gmane.org 1476896725 7835 195.159.176.226 (19 Oct 2016 17:05:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2016 17:05:25 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDQM7AFVVUERBROPT3AAKGQE6ZW4G5I@isocpp.org Wed Oct 19 19:05:21 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f197.google.com ([209.85.223.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwuIj-0000d8-7u for gclcip-std-proposals@m.gmane.org; Wed, 19 Oct 2016 19:05:13 +0200 Original-Received: by mail-io0-f197.google.com with SMTP id 64sf45574986ior.6 for ; Wed, 19 Oct 2016 10:05:15 -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=DcWfiL2Xtnv3KL8zQcP8t7/Ct2LoAcVJi30zTtjkFf8=; b=Py3REdKo53Kvx893Oa0AZoqOEa+bqOBxfRfDSSH4HXqqJzZj+A3nPVoiNoWuOhmIRw 2+zneNBiitWe0BeQgjzUHacyZds4fP4mwnWIMZLFlCUGb5iR7/s7/IK5FRezY1ekIKq1 paR5krl9fIHelJbqQMsBpCS+YP/WObNYURwh/A7wf4uIsc1O0LRRmccHeaDNZTPJG1hm SAM51Icyr83JliCBhs6QVl2/wAY44gGBOGQpLzFWzlyFbAt9ZLrEJsHASN3Nwj6RgfSv orVIULd+zyjrqtpV+L1o/Kgy3vp90O5z2H1zJs1fFLTtbvf1i0O/pezH3o7wFPdFXBsZ v3XQ== 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=DcWfiL2Xtnv3KL8zQcP8t7/Ct2LoAcVJi30zTtjkFf8=; b=t7JISoUKWAEf/9zw1k2ik50UuCOi4cRDgzEfzMOOYgr/KfqUU9iRWWIdhkjImo34B5 GhYw8LwwbABjUO6BSHD+7jtY1gihmrZ1v5ZtpALCf/6QWUSun1PmO0Ef/atpsGiNqK4Q M+ik++/hueQ6uFMZldlZHl+nz0D4Dn1Zn/Z5A66XrOG3TbxFSI40SuQQdENlJRd18ABD BWCXdLXt+e907QhmYmk1OF18ePMwwrKZULB2WJpMek6Vn+EC8vnDvFl5oJ9BDVL65n2X gbqjOqamLKJGLPwJf4HjPOdxk8NQu959lGbxgW5M8XN39lS9rtF0QhVk698Q/RGjnRGR 6SSw== 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=DcWfiL2Xtnv3KL8zQcP8t7/Ct2LoAcVJi30zTtjkFf8=; b=lKwzGmQ1Fzs/hjMW7brwMDg/Q388GtLoSd+rD333pjJVrFJmG6FaQcgKwsj3FmxaMX 9bMkXAHw/JwBHdx9b7ot16fgsxax0zfFNsjSSXgxgtOuBzRiZcfBdbFd6Js3D0duM0Iq kKMsZaydcgoNk7FAXoIxJIfE30u3ucAZoYTcJ+YpU27s2qkNNV1yoBA1SujQ1GOA4zXk PTYktxuiPmFLqCJlOawLhcZfbgbt7Q6x3onWkn8KJcw7V1tYFYxLUc0HwTJznyt3XzR9 ssOW6sOrN4tkJ6WHuUi88D4JNnTuoFk2OCJuj0tBuFeHl2r+NCrqJbO03w3fBAS80LTL LWbw== X-Gm-Message-State: AA6/9RnBRYAHifop+ba/d8aDD8WwkF1zqIx7UUTJ3xtaiW+bi40JzXncSwh4201CtjfY1Q== X-Received: by 10.36.33.200 with SMTP id e191mr2374938ita.12.1476896714214; Wed, 19 Oct 2016 10:05:14 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.51.77 with SMTP id k74ls971214itk.4.gmail; Wed, 19 Oct 2016 10:05:08 -0700 (PDT) X-Received: by 10.36.29.70 with SMTP id 67mr405022itj.1.1476896708835; Wed, 19 Oct 2016 10:05:08 -0700 (PDT) In-Reply-To: <39f69270-f3f8-412c-82ac-f192d2642185@isocpp.org> X-Original-Sender: joseph.thomson@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:28978 Archived-At: ------=_Part_535_1231100927.1476896707571 Content-Type: multipart/alternative; boundary="----=_Part_536_396352013.1476896707571" ------=_Part_536_396352013.1476896707571 Content-Type: text/plain; charset=UTF-8 Something like observer_ptr should exist. Use of raw pointers is simply too overloaded. Even if you buy the argument that, in modern C++, raw pointers have a single accepted use as non-owning references (and I don't**), something like observer_ptr narrows the range of operations to what is sensible for such a reference type (e.g. no pointer arithmetic). However, I believe the design of observer_ptr is not well tailored to its purported purpose: - *It is cumbersome to use*: any pointer can be "observed" safely, so why do I have to use make_observer or reset to change what I'm observing? This seems to be due to observer_ptr being based on unique_ptr (hence the inappropriate release function) which understandably wants to prevent accidental assignment of arbitrary raw pointers, since it takes ownership of whatever it holds. The API is appropriate for an owning pointer, not an observing pointer (p.s. the presence of a reset function would be a bike shed issue if direct assignment were possible). - *It has a null state*: this is sometimes desirable, but references are frequently used instead of pointers to "observe" something while precluding the possibility of not observing anything. Of course, pointers can be used, but care must be taken not to dereference a null pointer; it is better (IMO) to have compile-time assurance that your reference type cannot be null. Where the the null-less counterpart to observer_ptr? - *It is not const-correct*: pointers circumvent the "const-correct" nature of the C++ type system; a const pointer is not implicitly a pointer to const. This should be the default behaviour of any "observer" type. In fact, this should be the behaviour of any "owner" type as well; I feel as though unique_ptr and shared_ptr should have really been called unique_owner and shared_owner, and should have exhibited const-correct behaviour. That said, I can see value in the flexibility of pointer-like owning types, so perhaps we are in need of both sets of types (that is, if propagate_const cannot solve the issue satisfactorily; I'm not yet sure it can). I am aware of the existence of not_null in the GSL, as well as the proposed propagate_const wrapper. However, I'm not sure how I feel about littering my code with these beauties: propagate_const>> obs = make_observer(&obj); Imagine the compiler errors. In addition, there are a number of other issues: - not_null may not support smart pointers . - not_null isn't necessarily guaranteed to not be null, and may have run-time overhead if it is. - not_null isn't proposed for inclusion in the standard AFAIK. - propagate_const disables all copying, even when it is technically possible (e.g. T* to T* or T* const to T const*), which is hugely limiting when dealing with "observer" types. - propagate_const is designed with a very limited "pointer-like" interface; it is likely to be of limited use for "smart wrappers" which do not adhere to the pointer model (a problem if you want a null-less counterpart to observer_ptr). What's more, you have to ask, why are we starting with a type which is ill-fitting to model a const-correct, not-null observer type (T*) and then layering it with various wrappers designed to mould it into something which fits the bill? Wouldn't it be better to design separate wrapper types which just do the job? observer obs = obj; optional_observer opt_obs = obj; This is infinitely more desirable IMO. It's worth noting that, while is dislike the idea of using not_null for anything other than sanitizing legacy code (and the designers seem to agree, seeing as they want it to support only raw pointers), I am aware (I think) of why propagate_const is designed the way it is. If propagate_const could be redesigned to be more general and flexible (and I believe it may, if the Smart References through Delegation proposal were accepted), then *perhaps* it would make sense to leave it the responsibility of applying const-correctness to a "smart wrapper" API. propagate_const> obs = obj; Just my two cents. ** Raw pointers are used in low-level code for all sorts of uses; and anyway, I assume it is better to be explicit that assume people know what you mean. -- 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/21f90a12-3d1f-4f65-8974-66ee3a17f88d%40isocpp.org. ------=_Part_536_396352013.1476896707571 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Something like observer_ptr should exist. Use of raw pointers is simply to= o overloaded. Even if you buy the argument that, in modern C++, raw pointer= s have a single accepted use as non-owning references (and I don't**), = something like observer= _ptr narrows the range of operations to what is sensible for such a = reference type (e.g. no pointer arithmetic). However, I believe the design = of observer_ptr = is not well tailored to its purported purpose:
  • It is cumberso= me to use: any pointer can be "observed"= safely, so why do I have to use make_observer or reset to change what I'm observing? This seems to be = due to observer_ptr being based on uniq= ue_ptr (hence the inappropriate release function) which understandably wants to prev= ent accidental assignment of arbitrary raw pointers, since it takes ownersh= ip of whatever it holds. The API is appropriate for an owning pointer, not = an observing pointer (p.s. the presence of a reset function would be a bike shed issue if d= irect assignment were possible).
  • It = has a null state: this is sometimes desirable, but references are frequ= ently used instead of pointers to "observe" something while precl= uding the possibility of not observing anything. Of course, pointers can be= used, but care must be taken not to dereference a null pointer; it is bett= er (IMO) to have compile-time assurance that your reference type cannot be = null. Where the the null-less counterpart to observer_ptr?
  • It is not const-correct: pointers circumvent the "const-cor= rect" nature of the C++ type system; a const pointer is not implicitly= a pointer to const. This should be the default behaviour of any "obse= rver" type. In fact, this should be the behaviour of any "owner&q= uot; type as well; I feel as though unique_ptr and shared_ptr should have really been called unique_owner and shared_owner, and should ha= ve exhibited const-correct behaviour. That said, I can see value in the fle= xibility of pointer-like owning types, so perhaps we are in need of both se= ts of types (that is, if not_null in the GSL, a= s well as the proposed = propagate_const wrapper. However, I'm not sure how I feel about = littering my code with these beauties:


    =C2=A0 propagate_const<not_null<= observer_ptr<T*>>> obs =3D make_observer(&obj);
    <= /p>


    Imagine the compiler errors. In addition, there are a number = of other issues:
    • not_null may not support smart pointers.
    • not= _null isn't necessarily guaranteed to not be null, and may have = run-time overhead if it is.
    • not_null isn't proposed for inclusion in the standa= rd AFAIK.
    • propa= gate_const disables all copying, even when it is technically possibl= e (e.g. T* to T* or T* const to T const*), which is hugely limi= ting when dealing with "observer" types.
    • propagate_const is designed with= a very limited "pointer-like" interface; it is likely to be of l= imited use for "smart wrappers" which do not adhere to the pointe= r model (a problem if you want a null-less counterpart to observer_ptr).

    What&#= 39;s more, you have to ask, why are we starting with a type which is ill-fi= tting to model a const-correct, not-null observer type (T*) and then layering it with vario= us wrappers designed to mould it into something which fits the bill? Wouldn= 't it be better to design separate wrapper types which just do the job?=


    =C2= =A0 observer<T> obs =3D obj;

    =C2=A0 optional_observer<T> opt_obs =3D = obj;


    This is infinitely more desirable IMO. It'= ;s worth noting that, while is dislike the idea of using not_null for anything other than s= anitizing legacy code (and the designers seem to agree, seeing as they want= it to support only raw pointers), I am aware (I think) of why propagate_const is designed= the way it is. If prop= agate_const could be redesigned to be more general and flexible (and= I believe it may, if the Smart References through Delegation prop= osal were accepted), then perhaps it would make sense to leave it th= e responsibility of applying const-correctness to a "smart wrapper&quo= t; API.

    <= br>

    =C2=A0 propag= ate_const<observer<T>> obs =3D obj;


    Ju= st my two cents.

    ** Raw pointers are used in low-level code for all = sorts of uses; and=20 anyway, I assume it is better to be explicit that assume people know=20 what you mean.

--
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/21f90a12-3d1f-4f65-8974-66ee3a17f88d= %40isocpp.org.
------=_Part_536_396352013.1476896707571-- ------=_Part_535_1231100927.1476896707571-- .