220 36725 article Path: news.gmane.org!.POSTED!not-for-mail From: Richard Hodges Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Static analysis and the future of C++ Date: Sat, 20 Jan 2018 17:48:16 +0100 Lines: 785 Approved: news@gmane.org Message-ID: References: <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@isocpp.org> <88864914-82a8-4a8b-bda7-cffd38379edf@isocpp.org> <4fa792ec-1f51-4357-a65a-2ce3c10c60c0@isocpp.org> <00d91d4c-4ee7-4dbd-a547-3dd844f5685d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c0b91f0b6b8d0056337f6de" X-Trace: blaine.gmane.org 1516466792 6299 195.159.176.226 (20 Jan 2018 16:46:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 20 Jan 2018 16:46:32 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD4PBM7UWAHRBUPFRXJQKGQESZV247Y@isocpp.org Sat Jan 20 17:46:28 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f198.google.com ([209.85.223.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ecwHW-0000Vs-Mf for gclcip-std-proposals@m.gmane.org; Sat, 20 Jan 2018 17:46:15 +0100 Original-Received: by mail-io0-f198.google.com with SMTP id b184sf5189266iof.21 for ; Sat, 20 Jan 2018 08:48:19 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1516466898; cv=pass; d=google.com; s=arc-20160816; b=exIt3wLJAWzIICQX4xiFnvdbIharhHEdXn8r+GDX1EhnJywbWyx0tdZ0gIfGAmZl1C rDjnBLO09CwqhTkAne3EdHNe8/B/bSrSfTzrVpbMo7DFIXVkXsSL1UT4zjW7bJqpASb4 6cV8wkLie/4vb+em9ZLrP4Bn8pOK0E3OKg5re0S/5YXyWqXH0k4KXDYpw+k+v6vpAFR/ yrp9+WcUS4OPwwgiHreR9ZNcjqZhCu5+vAFQkZAdg1g1Hj6ZOrK/dPZxSGZtI884C2zP F4MJ7t0FK0dwsvdzoCP32Fvm/U4tAtrLex/kPoWLrmXLq7UXMU0UXb7xweuP0AO5T/+M nBJQ== 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=MBeO7HKsDEpM8p6U6ADC5G1aePcN/RIiHlf3AigSWo8=; b=ZVLNtQJks7JClil0TT6zwVeWX2uGT1KJ1hBFN+QmKtJcU8PCMXGoqGznUSbyLuDUGm v6fjaC0ZUB7JSb+/4Ut1y67VCAXzGLmdv5N6yQWBfFqLLsculNEDqIa+GIj0gTXv8hwX OqheDBZRMYLlF2RNNplMXrUbrC342SWVWO8bQTUAh1KpsyXoJtH0boUo7i9NGkUIaM93 rLXuh17qT8DnNiYRJd6NP6dppTtoB7Dg8tr4tcR5+g4dwglSWmzK2R5CJaamISTpqduX W7VDVfLqM1LGci4c5v3Ywah/TDy0zSW0Eq9DuQ69x/ZoOaJBB21dKeHYJG5J2A2aQXdY Jryw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Q393fUVW; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hodges.r@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=MBeO7HKsDEpM8p6U6ADC5G1aePcN/RIiHlf3AigSWo8=; b=snS7XL9tZDM3eK0NEEEyEp0glbCituqnG0ZQ32iy7FY5vRGc0YlJist6KIN4Dwi3uS 8WCyPZcCbugHpwBqgC1uoH42BZREbiHDgeuTLUMbdvcIBj9tFb57I4sA/vJhUVXhos2S qVVUwk4wTnbfCXfbEjPueGPvVaHxSVihlKT8Xz+vdRHpkBLZAlRwnPZjpTBFY3dbZETA wVnXZwmYthsJAE+Uq9uPaOL5R90qdKRQzUOrMPPKITFvLvc5515EqBLKyHKH7USXqj6L v9XQgomP56DjXEh4vS03HkSC0WJhUwpkt0CgHHfSRc8E5BES3Ov4sAJf1rwpqZibZoj0 7Wsg== 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=MBeO7HKsDEpM8p6U6ADC5G1aePcN/RIiHlf3AigSWo8=; b=XHMSgCQUsgCT58I2YdpRvkxq2pcesgDTeh7pNRwCXSLLNpOszjEp7CFgAXWl0WSNG3 XnlBtngYNtJmN6V+fLU0r6HCwv3PjGJRKyL31hcypb4frlavbY7ejrDUzfh4L3T2xkZx iaGCTzq9FozuSswLoWlYz7dX7cbBu/J4un04VIbq/x/Y0X1A/SPvMPVQpRk5GKCD8USO 4pg8kGwOI02ub70ufsR+5W76PXr3pquvI7ajPSMVfmrfGwVBhPbeukM7iRDGPDfPzmHY 3XPW0RAbMZCYEqI8UFICmVNBkIBSm6MT3EYNpzIXF5dmr6UQurUVZWB/Wat/xKTi/39V AhcQ== X-Gm-Message-State: AKwxyteyKQq7rUi3MV/kkniomj1cn2Z58fe+iGh/QS/LH8EchqBcA4tE r/G0AFuqGnAOjxEB43/lt9SdCA== X-Google-Smtp-Source: AH8x227nCQFVb+sTbVHMnAvc9+vSQb3XHKlfCxP6MKqDeOp6fsyp906fljLS1vByJDpiOr/rUPFVSA== X-Received: by 10.107.12.227 with SMTP id 96mr1770243iom.106.1516466898728; Sat, 20 Jan 2018 08:48:18 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.174.24 with SMTP id x24ls892112ioe.23.gmail; Sat, 20 Jan 2018 08:48:17 -0800 (PST) X-Received: by 10.36.39.138 with SMTP id g132mr2115856ita.89.1516466897494; Sat, 20 Jan 2018 08:48:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516466897; cv=none; d=google.com; s=arc-20160816; b=PsDRHq+6WhDWZP1BrvoZVf0PwG55SCFVEjcM0TQV8LeLYAp/8DuYm5phz3SGPOC7pN PtsqcMaL0wS7ZA+Hayo2AmOPElkTkkL/cQl4snYLG5LW5CZy2yAG35DJKaOseiDLjXqM rHDNQ2JPxfK+gJ1wZiP4zWC1mBU3oyM++zheTXsOdInuti/IvLjUhBbl7wbzta6lZhyt Egvnq0k1PGkq/Cd1Jed8oE8jp7O+MOR1w4YcCAKFEGOOcXBdDK8mUvOD/3VKGzu27nju ubhtX9wcAaX4X6VqMjYU7OCtgivR1mw7Pkxu4Fb92pnqXmTP9lafmWdUgvjPP70hbkqs YA2g== 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=mJYieJNEBEhE9rLtVwsSgBCzjHSaef8ZLqz7DPQdbBc=; b=IZ1X2cYx3+jfhutq6X08c2IiWzqK2a8EA3WdShKtp7G8i/zehGJDDNssiFYQ+b/DYK rCoxGHM7BlwxdTL5bBQiCQaiymFe9P8gouNcO3C3VC47g4m+yp0dGddyCPlKdHwIooYc dWOERPgRCH68eJcAsDERMECD3qn2Q4EQvJZNAtBk/t1AzU5YO//7RK0lPKArn0cwuq3K b9DNqC+1SHlxr8BfjS5YlDb1dD0aiHU1bdQrNajSYKh8Guz3ynvy7SxGYcPtSQ1MXNwF ExFGANOV1RMNIDD+rl9cnUIeM9U1xsGcQr8D/soQUuJRCRxWSN32Ojaie29+GXWKV01g KMVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Q393fUVW; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hodges.r@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id 66sor1305130iow.283.2018.01.20.08.48.17 for (Google Transport Security); Sat, 20 Jan 2018 08:48:17 -0800 (PST) Received-SPF: pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.107.183.78 with SMTP id h75mr2337145iof.201.1516466897072; Sat, 20 Jan 2018 08:48:17 -0800 (PST) Original-Received: by 10.2.164.138 with HTTP; Sat, 20 Jan 2018 08:48:16 -0800 (PST) In-Reply-To: <00d91d4c-4ee7-4dbd-a547-3dd844f5685d@isocpp.org> X-Original-Sender: hodges.r@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Q393fUVW; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hodges.r@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-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:36725 Archived-At: --94eb2c0b91f0b6b8d0056337f6de Content-Type: text/plain; charset="UTF-8" > In your example, the compiler should warn it can't predict the observer - has no visibility over its lifetime and/or the observed destruction is behind real time uncertainty. > He might even suggest alternative like share/weak ptr, because *observe_ptr was not the right tool in the first place!* The compiler will only reaffirm that fact. That would indeed be a useful feature. On 20 January 2018 at 17:36, wrote: > > > On Saturday, January 20, 2018 at 4:54:53 PM UTC+2, Richard Hodges wrote: >> >> > Copies of observer_ptr still monitor the same address, but with a >> different scope - their dtor, release or reset. >> >> It would be nice if this were enough. >> >> consider >> >> auto& exec = some_async_executor(); >> auto up = std::make_unique(); >> >> auto p = observer_ptr(up.get()); >> exec.post([p] { something_with(*p); }); // A >> exec.post([up = std::move(up)] { something_with(*up); }); // B >> exec.post([p] { something_with(*p); }); // C >> >> Assume that B's lambda invocation may or may not complete before C's lambda >> invocation. >> >> I can't see how this could be statically analysed. It's an undetectable >> logic error, since as far as the compiler is concerned, it has no way of >> knowing that C's p may outlive B's up. >> >> Note that at the point of the construction of each of the 3 lambdas, the >> pointers captured are all valid (except in the crossing case where there is >> a context switch after the post at B). >> > > > In any case this does heap allocation for the views (the lambdas, inside > the exec class) and presumably threading after that. Both are impossible to > track. > > > For both however we have nice tools - shared and week ptr. > > Which is ironic - the complex code is more safe then the trivial one. Yes > you could use the heavyweight tools for simple tasks, but that is not zero > overhead any more. > > Static analysis is the tool to help us with the common, simple, yet > (terribly) unsafe tasks, still keeping zero overhead. > > > Having said that, there are scenarios where tracking will not give > accurate prediction - the destruction might, for instance, depend upon some > real time state. > That is the reason, these cannot be errors, only warnings. > The compiler should, however, be able to see all paths leading to > destruction even the once behind real time check/uncertainty and warn that > "it *might *dangle" or that "no one can be certain, even you!". > > In your example, the compiler should warn it can't predict the observer - > has no visibility over its lifetime and/or the observed destruction is > behind real time uncertainty. > He might even suggest alternative like share/weak ptr, because *observe_ptr > was not the right tool in the first place!* The compiler will only > reaffirm that fact. > > > >> >> >> >> On 20 January 2018 at 12:12, wrote: >> >>> >>> >>> On Friday, January 19, 2018 at 10:19:40 PM UTC+2, Nicol Bolas wrote: >>>> >>>> On Friday, January 19, 2018 at 7:30:52 AM UTC-5, mihailn...@gmail.com >>>> wrote: >>>>> >>>>> Can we "just" define special behavior of observer_ptr (in >>>>> debug/analyze mode) and solve all cases of lifetime monitoring (under the >>>>> said limitations) - from smart pointers to function_view? >>>>> >>>> >>>> That's not "behavior" of the type. There is no actual code in >>>> `observer_ptr` that does anything you're talking about. It's simply a >>>> compiler or tool that sees you using this particular type and starts >>>> looking at things because of it. >>>> >>> >>> If the constructor and reset of observer_ptr are decorated with >>> something like [[debug:observe_destruction]] the behavior of observer_ptr >>> will be enforced by the compiler. >>> >>> The behavior, use and definition of observer_ptr are not changed. >>> >>> >>>> >>>> It should also be noted that this still doesn't handle perfect >>>> forwarding. Not unless it is the caller of the function who wraps the >>>> parameter in an `observer_ptr`. >>>> >>> >>> class A_view >>> { >>> A_view(const A* pa) : _p(pa) {} >>> A_view(const A& a) : _p(&a) {} >>> A_view(A&& a) : _p(&a) {} >>> >>> observer_ptr _p; >>> }; >>> >>> observer_ptr will monitor addressof(*_p) for ~A() call. The scope of >>> monitoring is ~observer_ptr() or release() call. >>> >>> Copies of observer_ptr still monitor the same address, but with a >>> different scope - their dtor, release or reset. >>> >>> >>> That is a major difference from lifetime extension - we can have >>> many-to-one mapping without any semantic or implementation problems. Lifetime >>> extension does not allow copies of a view/ref to extend with the lifetime >>> of the object. >>> We are also not limited to initialization only - the monitoring can >>> (re)start at the call of reset() instead on constructor call only. Lifetime >>> extension deals with initialization exclusively. >>> >>> >>> How can perfect forwarding interfere in all this? >>> >>> >>> template >>> auto init(Args&&... arg) >>> { >>> return T(std::forward(arg)...); //< observer_ptr starts >>> monitoring &arg >>> } >>> >>> int main() >>> { >>> auto v = init(A{}); //< both A_view and A allocated. A_view >>> usable before the ';' when ~A is called >>> } >>> >>> If copy elision does not kick-in nothing changes - copy is safe and >>> defined, lifetime of A is the same. >>> >>> If we pass arguments and create A in init() instead ( return >>> T(A(std::forward(arg)...)); ), then the observer_ptr is still >>> created with a valid address, >>> however, after we return will not be able to use A_view in any way, >>> including before the ';'. >>> >>> If both there is no elision and A is created when initializing T inside >>> init, then the returned view can be created from a dangling view. >>> We could allow views from dangling views to be created, however no dtor >>> will be monitored and all uses of the view will be illegal until >>> destroyed/reset/release-ed. >>> We could also issue a warning on coping from dangling view without >>> problem. >>> >>> >>> >>> >>> >>> >>> -- >>> 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-proposal...@isocpp.org. >>> To post to this group, send email to std-pr...@isocpp.org. >>> To view this discussion on the web visit https://groups.google.com/a/is >>> ocpp.org/d/msgid/std-proposals/4fa792ec-1f51-4357-a65a- >>> 2ce3c10c60c0%40isocpp.org >>> >>> . >>> >> >> -- > 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/00d91d4c-4ee7-4dbd- > a547-3dd844f5685d%40isocpp.org > > . > -- 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/CALvx3hbdgOOP14o37Wdx5VpuQTS%2BM-%2BMP7GXGbkLeTViiUsHcA%40mail.gmail.com. --94eb2c0b91f0b6b8d0056337f6de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0In your example= , the compiler should warn it can't predict the observer - has no visib= ility over its lifetime and/or the observed destruction is behind real time= uncertainty.=C2=A0
> He might eve= n suggest alternative like share/weak ptr, because=C2=A0observe_ptr was = not the right tool in the first place!=C2=A0The compiler will only reaf= firm that fact.=C2=A0

That would indeed be a usefu= l feature.


On 20 January 2018 at 17:36, <mihailnajdenov@g= mail.com> wrote:


On Saturday, January 20, 2018 at 4:54:53 = PM UTC+2, Richard Hodges wrote:
>=C2=A0Copies of=C2=A0observer_ptr still monitor the same addre= ss, but with a different scope - their dtor, release or reset.
<= span style=3D"font-size:13px;background-color:transparent;margin:0px;paddin= g:0px;border:0px rgb(34,34,34)">
It would be nice if this were enough.

consider

=
auto& exec =3D some_async_executor();
auto up = =3D std::make_unique<Foo>();

auto p =3D observer_ptr(up.get());
exec.post([p] { = something_with(*p); });=C2=A0 =C2=A0 // A
exec.post([up =3D std::move(up)] { = something_with(*up); }); // B
exec.post([p] { something_wi= th(*p); });=C2=A0 =C2=A0// C

Assume that B= 9;s lambda invocation may or may not complete before C's=C2=A0lambda invocation.
=
I can't see how this could be st= atically analysed. It's an undetectable logic error, since as far as th= e compiler is concerned, it has no way of knowing that C's p may outlive B's up.

Note that at the point of the construction of each of the 3 lambdas= , the pointers captured are all valid (except in the crossing case where th= ere is a context switch after the post at B).


In an= y case this does heap allocation for the views (the lambdas, inside the exe= c class) and presumably threading after that. Both are impossible to track.=


For both however we have nice too= ls - shared and week ptr.=C2=A0

Which is ironic - = the complex code is more safe then the trivial one. Yes you could use the h= eavyweight tools for simple tasks, but that is not zero overhead any more.= =C2=A0

Static analysis is the tool to help us with= the common, simple, yet (terribly) unsafe tasks, still keeping zero overhe= ad.


Having said that, there are sce= narios where tracking will not give accurate prediction - the destruction m= ight, for instance, depend upon some real time state.
That is the= reason, these cannot be errors, only warnings.
The compiler shou= ld, however, be able to see all paths leading to destruction even the once = behind real time check/uncertainty and warn that "it might dang= le" or that "no one can be certain, even you!".
In your example, the compiler should warn it can't predict= the observer - has no visibility over its lifetime and/or the observed des= truction is behind real time uncertainty.=C2=A0
He = might even suggest alternative like share/weak ptr, because observe_ptr = was not the right tool in the first place! The compiler will only reaff= irm that fact.=C2=A0

=C2=A0
<= br>


On 20 January 2018 at 12:12, <mihailn...@gmail.com> wrote= :


On Friday, January 19, 2018 at 10:19:40 PM UTC+2= , Nicol Bolas wrote:

If the cons= tructor and reset of observer_ptr are decorated with something like [[debug:observe_destruction]] the=C2=A0behavior of=C2=A0observer_ptr will be enforced by the compiler.

The behavior, use and definition of observer_ptr are not changed.= =C2=A0
=C2=A0

It should also = be noted that this still doesn't handle perfect forwarding. Not unless = it is the caller of the function who wraps the parameter in an `observer_pt= r`.

class A_view
{
=C2=A0 A_view(const A* pa) : _p(pa) {}
=C2=A0 A= _view(const A& a) : _p(&a) {}
=C2=A0 A_view(A&& a) : _p= (&a) {}

=C2=A0 observer_ptr<const A> _= p;
};=C2=A0

<= /div>
observer_ptr will monitor address= of(*_p) for ~A() call. The scope of monitoring is ~observer_ptr() or relea= se() call.

Copies of=C2=A0observer_ptr still monitor = the same address, but with a different scope - their dtor, release or reset= ..=


That is a major difference from lifetime exte= nsion - we can have many-to-one mapping without any semantic or implementat= ion problems.=C2=A0Lifetime extension does no= t allow copies of a view/ref to extend with the lifetime of the object.
We are also not limited to initialization only = - the monitoring can (re)start at the call of reset() instead on constructo= r call only. Lifetime extension deals with initialization exclusively.=C2= =A0

=
=



If copy elision does not kick-in nothing changes - copy is safe and defin= ed, lifetime of A is the same.


=


=C2=A0

--
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.o= rg.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-pr= oposals/4fa792ec-1f51-4357-a65a-2ce3c10c60c0%40isocpp.org.

--
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-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/00d9= 1d4c-4ee7-4dbd-a547-3dd844f5685d%40isocpp.org.

--
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/CALvx3hbdgOOP= 14o37Wdx5VpuQTS%2BM-%2BMP7GXGbkLeTViiUsHcA%40mail.gmail.com.
--94eb2c0b91f0b6b8d0056337f6de-- .