220 33042 article Path: news.gmane.org!.POSTED!not-for-mail From: "Arthur O'Dwyer" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: std::optional - support for sentinel values Date: Fri, 30 Jun 2017 10:24:28 -0700 Lines: 286 Approved: news@gmane.org Message-ID: References: <6e23864f-827a-4bdb-89de-a60d8f5be993@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c0de4748b8b39055330b0e7" X-Trace: blaine.gmane.org 1498843478 18589 195.159.176.226 (30 Jun 2017 17:24:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Jun 2017 17:24:38 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBDLZJYWNDQIM5EW2ZICRUBGVR3ECG@isocpp.org Fri Jun 30 19:24:26 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f72.google.com ([209.85.215.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQzec-0004G0-54 for gclcip-std-proposals@m.gmane.org; Fri, 30 Jun 2017 19:24:26 +0200 Original-Received: by mail-lf0-f72.google.com with SMTP id c199sf29610557lfg.8 for ; Fri, 30 Jun 2017 10:24:31 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1498843471; cv=pass; d=google.com; s=arc-20160816; b=z1a/Dp3EYmocSiVVjelP3VQ/wnMaR70YHguXCCsngPKUgzz1Un5qegB8d9NTq5iD9P 6pMF91s6Ic/RrG3s723Kw3645HFFIVot86bb/P5892n9IRU+/powNfEl+d2x2iPbCWhy ue3bvN4WCtM+cuv/dk6iCg6pcrEP/dbplZ9ePYOeoay9G0+qLR0Qn07ials7I2Oq0hnB +hgNX2g55rXa+NMfgRhVWzQKIDQU7O2LawtU3DDi+oJsWAxyLROqDp8jQ4Qr50bmoIX3 IDIaOXsAEEkGuhiW2qM6KvGTbl49Pet26F5oQWFStD82OZXY9FvtBKX7PMBEGtanL7XZ IbQg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=0OAo0YFweMnTtYPW9079AMv74UgG6yjm75hSft+wwBY=; b=DDJuYcpOpCiE+Rw94wQft2L3lPw55uVrlQHAlkM3kzA3r78dYXHveyzjFOVO1sLbSX LhQpQv2KLIiVxJJAaxDU06UJyHjNPRo1i4ygpdOyfsclppxwaWZCCICmMFsDzhKJSWQ9 q2z1cMAr6aBtn/SLW2Sg6NZ45njpOWeyGzoRUfOjARplmIAk+l5J/H2t9PMxQPcbNuZL PMWx3SbQiL1bvyG21yB7w2X5d8unKXe1zpYheBFIyy3L9AiUlp/mK/RC4bNs27I62vnV hUQ4hDSG+t0ig3y5NG+0w9xjRBs2jrDBMI+O4enbNdxXNVI1/JOTqa5UgokpowM/iy2u XbjQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.b=NV5dNQtf; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 2a00:1450:400c:c09::22a as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :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=0OAo0YFweMnTtYPW9079AMv74UgG6yjm75hSft+wwBY=; b=EXm5OczWs0QZmIpVXv50gi9niG0lZnoyvO8B0VrXOeQvm83o404j9cAiD2IOKo84Tf z6LxUFOC/PhbXQ0sRx8CkrOcl7oteWjG0o9R/n2tc/VhUMyEwjyHnCbwTaxkXmPDczHq MBmzeVWLVXx2MkGIWVlrQRxj/vTbu4L8cRx3FyrJuMfoOYVpW0Q3BVBqGIuTg8s22ef7 TgbIbwzUQ7a2VaEZrJwLTu47JyNB2g6fw45QWm2dtu5lVPRFtdqWDJDyVZ8J4PVy315G U3+VFxCErxMenSMf+IzMeEQgb9yz19V+69sVDnzsubd6oK5S1VuuvcqrextXkGSJlYTN Tx2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=0OAo0YFweMnTtYPW9079AMv74UgG6yjm75hSft+wwBY=; b=Un0nxC4sZz98+InzI9a5xuDF2OvessjSkhyhj1x/BfPgCIXckENflr+IPs+SOhagYd dflvrMENi9NAOQhCSq0wVIhOfCStxzR4H9p6y9sD2dSH/YvnmwLvZrzrdRspwRlDEDiP rfWYkhwTKYsV+OjtmZd27GNrh1sv/EBmSAdjBurbN/v7TsXY25ansQXvHf5Oz6aXhCiT hiLV6TBx53c7Dv+Hcd1iTwgcuzNKZBl/U43kkdgwxSaIimnZ7bhV0RcK93wsRXcK9kYx /h9xaGZBk/bAYMVPSIdkV4yqNdNPQIpJGn74cPlfxPsFs6DBZPUyzxyMXRswb++egegq /ETw== X-Gm-Message-State: AKS2vOwKarftDeZGWG36jcZQogGBgphSytuyH2VQgLr79p9guwvcD1Zn wFt8EVRzcO2XuDp6 X-Received: by 10.46.80.18 with SMTP id e18mr4316527ljb.10.1498843471485; Fri, 30 Jun 2017 10:24:31 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.153.140 with SMTP id b134ls762897wme.23.gmail; Fri, 30 Jun 2017 10:24:29 -0700 (PDT) X-Received: by 10.28.113.142 with SMTP id d14mr7183914wmi.10.1498843469756; Fri, 30 Jun 2017 10:24:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498843469; cv=none; d=google.com; s=arc-20160816; b=G2ThKxv29F/spwYaMdW+npliw38beP0tjpcqDe+iDxlD1zobcOAj6nuBnRUJiL7OIx hN4R1Qq7jMi70E3fvE+Py+4U4Z02nRzLobSOzAsRdndv3U/NNPPL3SmzMTdhmImdip6a yEwR3AkyzdG5b4xGRY+rnGe+shPI751v5SG9GA9wq+durH2e6iFi3+tXOlNGGhEZGUBT kQ1lMbFZc/33ovuuqlNew+c+/pcgwzU/zNBITXumfkGe8fB6itaXfR4JLsMUFN76pzkN S1WAkOGPt3A5o1XomEz+V1LNKxU9C3pbGoFN1R/uXPiIzNmMH8ZRxgCQOdIPAQDLO6VR FUmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=uTFW5Bch0CXdquJbeTsodfcTEgid55zkOjFsI+cPybo=; b=LzIqC6OiQsIyXJFmtArOE4rbEJNUIRz3cuCpTuSIN0pZOY3qkYqb2DqXPs6e+cEQ1t xDbjdDnwaLH694u+mkDjhfSPJvzqSdd0nS3rHeQAiAYi9+m29dkZnKnZ4w+Vb7uGhKIn Secjhc53iUdM75TER2I5mJ/ra0/5lL9lZkPlzMm6g0ZZM1aZe7njPxAQ3xbEiIiOhrRM MRMWoqqAarhdMawbGmtNsYs4JoTCfDfdznA1Q6a+duc8Pbeh+Gl6wb5oz0yZQ0ulMqqe 2I7xoFwA+hsC1wE+khLEC2zTLB3TyEkRiCBILdV1gE9auVT4L/2eJbJK6e7dUdMdqAO/ IQ2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.b=NV5dNQtf; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 2a00:1450:400c:c09::22a as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com. [2a00:1450:400c:c09::22a]) by mx.google.com with ESMTPS id v29si5773346wra.109.2017.06.30.10.24.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jun 2017 10:24:29 -0700 (PDT) Received-SPF: pass (google.com: domain of arthur.j.odwyer@gmail.com designates 2a00:1450:400c:c09::22a as permitted sender) client-ip=2a00:1450:400c:c09::22a; Original-Received: by mail-wm0-x22a.google.com with SMTP id b184so52694889wme.1 for ; Fri, 30 Jun 2017 10:24:29 -0700 (PDT) X-Received: by 10.80.146.79 with SMTP id j15mr6259191eda.17.1498843469022; Fri, 30 Jun 2017 10:24:29 -0700 (PDT) Original-Received: by 10.80.173.204 with HTTP; Fri, 30 Jun 2017 10:24:28 -0700 (PDT) In-Reply-To: X-Original-Sender: arthur.j.odwyer@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.b=NV5dNQtf; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 2a00:1450:400c:c09::22a as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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:33042 Archived-At: --94eb2c0de4748b8b39055330b0e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jun 30, 2017 at 7:21 AM, Igor Baidiuk wrote: > On Friday, June 30, 2017 at 2:05:35 AM UTC+3, Arthur O'Dwyer wrote: >> >> Mark Zeren's C++Now talk on strings >> will be interesting to >> you. Following that talk, I implemented his ideas for a "nullable trait"= in >> my "STL From Scratch" under the name std::tombstone_traits. >> > Thanks, will check it. > > > >> Here are the problems with *your* approach: >> - Using a sentinel value of the type T is philosophically incorrect >> w.r.t. lifetime management. If I construct a disengaged optional, and th= en >> destroy it, I *must not* call the destructor of T. If I copy a >> disengaged optional, I *must not* call the copy constructor of T. If you >> unconditionally construct a T no matter whether the optional is engaged = or >> disengaged, then what you have is philosophically not an optional; it= is >> literally a T. If that's what you want, just write T. >> > > I disagree. > Following your thought, C++ is already incorrect w.r.t. lifetimes - some > value, which is moved out, is still accessible and requires destructor ca= ll. > Nope. An object of type T, even in a "moved-from state", still has a value of type T. That value might be unspecified; it might even have unusual restrictions on what you can do with it (although this is exceedingly rare); the most common case is that the object's value is some variety of "trivial value" (e.g. the empty std::string) or some variety of "empty value" (e.g. a std::future which is not valid(), or a std::function whose target_type() is typeid(void)). The way you can tell that the object still has a value (and therefore is still of type T) is that you're required to call the destructor ~T() on it (usually implicitly). Every object of type T must be destroyed by calling its destructor; and vice versa, you're only ever allowed to call ~T() on an object that really *is* of type T. > Next, I'm thinking more from correctness and usability points of view. > The values used for sentinels are usually "invalid" type states. The > closest example is what remains of value if it's moved out. In such case > destructor is trivial. > Well, that's just false. Go look at the destructor of std::unique_lock sometime, or std::future, or std::string, or std::shared_ptr. What happens if you move-out-of such an object? Does its destructor magically become trivial? > Next, such "invalid" state simply cannot be used in place of normal value= .. > Null pointer cannot be used to access object. In fact, pointers should ha= ve > never been allowed to be dereferenced, from philosophical correctness poi= nt > of view. Typed pointer is kind of abomination - it can be rebound to > arbitrary location via simple arithmetic operations, and it can be used t= o > access data like reference. > Here, I agree with you. Nullable pointers *are* the "billion-dollar mistake". And C++ gives us-the-user the power to correct that mistake! Let's make a non-nullable pointer type: class int_ptr { int *p_; public: int_ptr() =3D delete; int_ptr(int *p) { REQUIRE(p); p_ =3D p; ASSERT(p_); } int_ptr(const int_ptr& rhs) { ASSERT(rhs.p_); p_ =3D rhs.p_; } int_ptr& operator=3D(const int_ptr& rhs) { ASSERT(p_ && rhs.p_); p_ =3D rhs.p_; } ~int_ptr() { ASSERT(p_); } int& operator*() const noexcept { return *p_; } }; The copy operations and deleted zero-argument constructor are technically unnecessary, but I put them in so that we'd be able to talk sensibly about the invariants of this class type. I claim that the invariant of this type is "It is never NULL, and therefore it is always safe to dereference with operator*()." We have one "narrow contract" entrypoint that checks its arguments and throws (via the REQUIRE macro) if there's no way to build a legal (invariant-satisfying) int_ptr value out of those arguments. Okay. So now I have a non-nullable pointer type where NULL is actually excluded from the domain of values of this type. *Show me how you'd build a space-efficient std::optional using your mechanism.* I claim that you won't be able to do it, because, again, = *by definition*, every legal value of int_ptr is a legal value of int_ptr. You're never going to find a legal value of int_ptr that is "available" for your use, just like you couldn't find one for bool. A type always totally covers its domain, by definition: The domain of a type *is the set of all possible values* of that type. Similarly, I claim that if you tried to build a std::optional =E2=80= =94 an optional that could hold a nullable pointer or else be disengaged =E2=80=94= using your mechanism, you'd find it impossible to distinguish between std::optional o1 =3D std::nullopt; // this optional is disengage= d std::optional o2 =3D nullptr; // this optional is engaged, and holds a nullable pointer with value NULL If that's true, then what you've built isn't optional, because it can't hold "a nullable pointer *or* disengaged." What you've built is equivalent to either optional (because it can hold "a non-nullable pointer *or* disengaged") or simply int* (because it can hold "a non-nullable pointer *or* null", which is to say, it can hold "a nullable pointer"). This is why I said in my original response:=E2=80=94 If you mea= n "T", just *say* "T". Don't use the phrase "optional" to mean "T"; that's just going to confuse people. I've addressed your comments about tombstone_traits in my response to Matthew Woehlke. Hopefully that will help you see how it's implemented. The code is still available too. :) =E2=80=93Arthur --=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/CADvuK0KjALZ7qeXqLxrdL_Kf2tc460noqLZ3feosCvdELsz= _bQ%40mail.gmail.com. --94eb2c0de4748b8b39055330b0e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jun 30, 2017 at 7:21 AM, Igor Baidiuk <target.= san@gmail.com> wrote:
On Friday, June 30, 201= 7 at 2:05:35 AM UTC+3, Arthur O'Dwyer wrote:
Mark Zeren's C++Now talk on strings will= be interesting to you. Following that talk, I implemented his ideas for a = "nullable trait" in my "STL From Scratch" under the nam= e std::tombstone_traits<T>.
Thanks, will check= it.

=C2=A0
Here are the= problems with your approach:
- Using a sentinel value of = the type T is philosophically incorrect w.r.t. lifetime management. If I co= nstruct a disengaged optional, and then destroy it, I must not call = the destructor of T. If I copy a disengaged optional, I must not cal= l the copy constructor of T. If you unconditionally construct a T no matter= whether the optional is engaged or disengaged, then what you have is philo= sophically not an optional<T>; it is literally a T.=C2=A0 If that'= ;s what you want, just write T.

I disagree= ..
Following your thought, C++ is already incorrect w.r.t. lifetimes - so= me value, which is moved out, is still accessible and requires destructor c= all.

Nope.=C2=A0 An object = of type T, even in a "moved-from state", still has a value of typ= e T.=C2=A0 That value might be unspecified; it might even have unusual rest= rictions on what you can do with it (although this is exceedingly rare); th= e most common case is that the object's value is some variety of "= trivial value" (e.g. the empty std::string) or some variety of "e= mpty value" (e.g. a std::future which is not valid(), or a std::functi= on whose target_type() is typeid(void)).

The way y= ou can tell that the object still has a value (and therefore is still of ty= pe T) is that you're required to call the destructor ~T() on it (usuall= y implicitly). Every object of type T must be destroyed by calling its dest= ructor; and vice versa, you're only ever allowed to call ~T() on an obj= ect that really is of type T.

=C2=A0
Next, I'm thinking more from = correctness and usability points of view.
The values used for sentinels = are usually "invalid" type states. The closest example is what re= mains of value if it's moved out. In such case destructor is trivial.

Well, that's just false.= Go look at the destructor of std::unique_lock sometime, or std::future, or= std::string, or std::shared_ptr. What happens if you move-out-of such an o= bject? Does its destructor magically become trivial?

=C2=A0
Next, such "inva= lid" state simply cannot be used in place of normal value. Null pointe= r cannot be used to access object. In fact, pointers should have never been= allowed to be dereferenced, from philosophical correctness point of view. = Typed pointer is kind of abomination - it can be rebound to arbitrary locat= ion via simple arithmetic operations, and it can be used to access data lik= e reference.

Here, I agree = with you.=C2=A0 Nullable pointers are the "billion-dollar mista= ke".=C2=A0 And C++ gives us-the-user the power to correct that mistake= !=C2=A0 Let's make a non-nullable pointer type:

class int_ptr {
=C2=A0 =C2=A0 int *p_;
public:
=C2=A0 =C2=A0 int_ptr() =3D delete;
=C2=A0 =C2=A0 int_ptr= (int *p) { REQUIRE(p); p_ =3D p; ASSERT(p_); }
=C2=A0 =C2=A0 int_= ptr(const int_ptr& rhs) { ASSERT(rhs.p_); p_ =3D rhs.p_; }
= =C2=A0 =C2=A0 int_ptr& operator=3D(const int_ptr& rhs) { ASSERT(p_ = && rhs.p_); p_ =3D rhs.p_; }
=C2=A0 =C2=A0 ~int_ptr() { A= SSERT(p_); }
=C2=A0 =C2=A0 int& operator*() const noexcept { = return *p_; }
};

The copy operations and= deleted zero-argument constructor are technically unnecessary, but I put t= hem in so that we'd be able to talk sensibly about the invariants of th= is class type.
I claim that the invariant of this type is "I= t is never NULL, and therefore it is always safe to dereference with operat= or*()." =C2=A0We have one "narrow contract" entrypoint that = checks its arguments and throws (via the REQUIRE macro) if there's no w= ay to build a legal (invariant-satisfying) int_ptr value out of those argum= ents.
Okay. So now I have a non-nullable pointer type where NULL = is actually excluded from the domain of values of this type.

=
Show me how you'd build a space-efficient std::optional&l= t;int_ptr> using your mechanism. =C2=A0I claim that you won't be= able to do it, because, again, by definition, every legal value of = int_ptr is a legal value of int_ptr. You're never going to find a legal= value of int_ptr that is "available" for your use, just like you= couldn't find one for bool.=C2=A0 A type always totally covers its dom= ain, by definition: The domain of a type is the set of all possible valu= es of that type.

Similarly, I claim that if yo= u tried to build a std::optional<int *> =E2=80=94 an optional that co= uld hold a nullable pointer or else be disengaged =E2=80=94 using your mech= anism, you'd find it impossible to distinguish between

=C2=A0 =C2=A0 std::optional<int*> o1 =3D std::nullopt; =C2= =A0// this optional is disengaged
=C2=A0 =C2=A0 std::optiona= l<int*> o2 =3D nullptr; =C2=A0// this optional is engaged, and holds = a nullable pointer with value NULL

If that&#= 39;s true, then what you've built isn't optional<int*>, becau= se it can't hold "a nullable pointer=C2=A0or disengaged.&qu= ot; What you've built is equivalent to either optional<int_ptr> (= because it can hold "a non-nullable pointer or disengaged"= ) or simply int* (because it can hold "a non-nullable pointer or null", which is to say, it can hold "a nullable pointer").= =C2=A0 This is why I said in my original response:=E2=80=94 If you mean &qu= ot;T", just say=C2=A0"T". Don't use the phrase &q= uot;optional<T>" to mean "T"; that's just going to= confuse people.

I've addressed your comments = about tombstone_traits in my response to Matthew Woehlke. Hopefully that wi= ll help you see how it's implemented. The = code is still available too. :)

=E2=80=93Arthu= r

--
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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0KjALZ7qeXq= LxrdL_Kf2tc460noqLZ3feosCvdELsz_bQ%40mail.gmail.com.
--94eb2c0de4748b8b39055330b0e7-- .