220 38249 article Path: news.gmane.org!.POSTED!not-for-mail From: Richard Hodges Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Simple, terse universal forwading for the next decade Date: Tue, 29 May 2018 00:22:53 +0200 Lines: 391 Approved: news@gmane.org Message-ID: References: <80548757-8a42-499a-bf15-3670b2727082@isocpp.org> <8d3b34de-c06a-4083-bb0c-8e2c7482abf0@isocpp.org> <9930a9dc-b998-4431-a159-6d72d1d9b2ff@isocpp.org> <8e1c6607-a92d-496b-aad1-e992e049a748@isocpp.org> <2f782c2d-e89c-4d8b-8ef6-372c00e62ab1@isocpp.org> <93ee46a2-1469-48ae-b931-c060946f38d5@isocpp.org> <609892ba-f717-4458-b9e3-c5975378ad29@isocpp.org> <4d68237c-077a-4408-abf1-5f9670311f71@isocpp.org> <70fe7dc7-b8a6-4498-9aa6-f88e6af06506@isocpp.org> <0c4f8aa4-6b4f-4fe3-a02a-ef33eae990a8@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000c08aac056d4b8fd3" X-Trace: blaine.gmane.org 1527546060 2577 195.159.176.226 (28 May 2018 22:21:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 May 2018 22:21:00 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD4PBM7UWAHRBSUCWLMAKGQE4WV4EOY@isocpp.org Tue May 29 00:20:56 2018 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 1fNQVc-0000Z7-5G for gclcip-std-proposals@m.gmane.org; Tue, 29 May 2018 00:20:56 +0200 Original-Received: by mail-io0-f197.google.com with SMTP id f9-v6sf11603406iob.14 for ; Mon, 28 May 2018 15:23:07 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1527546187; cv=pass; d=google.com; s=arc-20160816; b=I0QQ8hEaNjqmyxTego1eUvOQjpKhQuHnE8LwAYOwTWnS5mq8uYiDZuL7W+vbrv1OFF IFTF5Rio4p0XUfmjGjnGajPXYRuM5Y8yIlWBBNs/9v4oG56YzboeO4b+uSw1uxLRfKuw 4LM+KHvVarjs7gWID5n2ITRgRW3CE0cgN57tmAb9Yk/CjTb1HGn4rWUMCI9wekEndBG8 d7LQtXb198F6XnbzwMZk8wDN9/0lpzuQ5LtH7XgXFNAEu/0n2hToLwyjkgtlV6ostg50 3OkeAQhAPJf8wyGgZv7IGhuA8sNjFMAUbYUwy56j7mJYAXTa6si/GK/7hklh8MYE4QcL lggw== 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:in-reply-to:references:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=gppJZsuzQbix6tKgxMhsJT+fhKQA5zmLG5YuNqhimCQ=; b=JpJfvNBIbbw0XJLbuta6NDeHF0px0UoOB6XeCsafcOGzRFzFJnEBV9istIiT5E/tgG jKaagr0rFudn5pMUOXd8kzZXutPaFDihMrXB5lM+/a+MYipwmGNcV10u00s58UOZRLSz 61A4YzTNJ9JxUXgSfqXfUh49zkSCzYwub6N3NqZ0xHRpAHZ3hGyNM11oblon/XJDUyzu CbRYJ1CB4oEKM52dhKPZIhmeIrCKaQY/P4Vf6Zph+ETMOJ6H5ozPKZfpBucmaUgYD7MZ zUFG1a1AlRF7b32qLlibIz07yPM4Yc24+svJCK24qmCroB3ydomLRwTehvGRi6mPMiAH Clkg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=D3JRuewf; 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=QUARANTINE 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:references:in-reply-to: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=gppJZsuzQbix6tKgxMhsJT+fhKQA5zmLG5YuNqhimCQ=; b=Dp1DHtXRH+LLHCqy1U8jRfE7RAb8CQtS2JFuv8YLIxfo6eSJFBt3gS7beKTF4Vg/W3 V8ZZTzVKnuwD1Euf+gRJ1jUPwXBKasz3vwDKpuEezvJgdujgGQXJup3GvmXLu5RI2yKd KwURK75Q8ju+S80NtmxyhYxMMM2ynb4gER0vRhLZAntivQLBfBwJEeI1UbT37003Zu3c Hx+U0L+PKXGP9RqGnUygmWbb9btPYcqpTI1ZmlstFL62T8Uyuxw+X8v0PuQL1Zn+4Pvw NoVS45iVJ5cA7FHi41I29mFVrBT9aYEvx7Cg/iDmRKE4XkEdDG4CurnNnZrzLNp8lXi3 fYpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to: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=gppJZsuzQbix6tKgxMhsJT+fhKQA5zmLG5YuNqhimCQ=; b=b75hISZkA2zaukFPj7XOBz96T3C2nE8jb9LWgJoxcbS2XH4HBdjoQj4WAmHjcORUnK 03B9gHpCwl5ehWR/QVQ+8Qv6+0fLlSohzTJRiTTDIoR53nwuvJZsuqX1XGv7lznKaVi2 LuixGCoqgcl+VV78OvVNB3YFHUfdkYgeSy0o/q5hl4seNmbix2mHMyqFykCXhjO+Wy3s qcn8m3MtJb7I5gEkCHMwmXLXcv5gj2hW/EF5PXE0r0tM2oN2ya7CTig8Hl7wQ7c7h/O1 MR2RwI/j9r2wcB+vLk5eJ3pbbgCXi0rLoAl4gq/1p+B21YRHY6PzwBWq2FpXJheyz1CL 3JvA== X-Gm-Message-State: ALKqPweODNoNnlv22ApWaIusNV7Qyt4UCVXd54D5Em7dYNKfm8wmpdPD mvb7yq1nxemm2U+nd+ju+tvq8g== X-Google-Smtp-Source: ADUXVKIoTs9PkrPH+lUV3l4wC1CPrMjncpO5vSuGvYicBWDnlfZyJHyEvtmQCYW9d3uh/V3g2hYrUQ== X-Received: by 2002:a24:4d02:: with SMTP id l2-v6mr6993761itb.7.1527546186968; Mon, 28 May 2018 15:23:06 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a24:6951:: with SMTP id e78-v6ls201990itc.10.canary-gmail; Mon, 28 May 2018 15:23:05 -0700 (PDT) X-Received: by 2002:a24:3cd7:: with SMTP id m206-v6mr5570392ita.113.1527546185803; Mon, 28 May 2018 15:23:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527546185; cv=none; d=google.com; s=arc-20160816; b=iGGEp82jcIhMBYv9QoGpD2JNzPy5MGMWDKA3C2xzYFWy/uAzUK4CV/Blaj55hj/w+l ud4OOu5ZRpYQ7i/4f0JRjmrYiIaAytXzfciHC85LbiQ4mFtYzVc0FZCiVI2QvgYvfxf0 QlWZnZGyc0C9LFL5gfxGXzEaEbg5goeyv80lkZ3NAVpoEirWKfs+v0OPz/cMmxoTWb/z 6n/P0fFhdCwcZQy00YKxDJSChDR8D9SGKItoqnDct866cPLgORDPtF1zc9kjmflqRvX1 cwwqRjiLtUFwukq262V3PRI8F0z2KKjej9Yg9FUH2GfYOkFhNVOUl6P3yO4vkjydMWZO UdsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature:arc-authentication-results; bh=e7+bvnD+U0aP/RdYFwM27bkx93jXHC1znVLcG/ihTG8=; b=N3NCjT8DmV7SMS5kqE7juTGhWfUL+pGQ8rSraILxs9M4YxxiMPEsZAnbXPt/CukGcY 5/WSdzv2ntmQ30reakOsyKo46d/ExuGlFdad+GoCZcrYTpDxQE4Ft2+y8FbGEKybmz+h g3XERlko2KvhSj4ukvleW8bok/88PWuMusU9aX/fhhOSkRvzgTReSNwfvZ4QIfTf3Rv3 iDY+ds8qeAVfUC2tI9lEIH0e3afJKS15EsEaxnsbpaF5+saOg8MfkyRBC7KuEAxDijYC HmSC2wpjgIkDvN1Otz0xHvl/yz80OJAk97HgePjJ9T0/0wM8u/udmqlSPKUHfwMADYRC yxyw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=D3JRuewf; 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=QUARANTINE 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 j204-v6sor15604423iof.155.2018.05.28.15.23.05 for (Google Transport Security); Mon, 28 May 2018 15:23:05 -0700 (PDT) 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 2002:a6b:2251:: with SMTP id i78-v6mr11583877ioi.276.1527546185286; Mon, 28 May 2018 15:23:05 -0700 (PDT) In-Reply-To: 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=D3JRuewf; 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=QUARANTINE 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:38249 Archived-At: --000000000000c08aac056d4b8fd3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Anyone proposing adding another operator to c++ has clearly not recently had to teach the language or maintain code. forward (or give, or similar) should be a keyword. I know the committee fears adding keywords, but this fear is unfounded. The constant hoop-jumping merely to avoid the inevitable simply creates technical debt which will impede design choices in the future. On Mon, 28 May 2018 at 22:26, Nicolas Lesser wrote: > That postfix && is problematic: > > auto Value =3D Arg && (Foo =3D=3D 10 || Foo =3D=3D 11); > > Today this would evaluate Arg and iff true see if Foo is 10 or 11 and > store that value in Value. > > What would this code mean with your operator? Would it instead be > interpreted as a forwarded Arg called whether Foo is 10 or 11? > Would it be ambiguous? How do you want to disambiguate between the two > meanings? > > On Mon, May 28, 2018 at 10:20 PM wrote: > >> >> >> On Monday, May 28, 2018 at 8:50:41 PM UTC+3, Ga=C5=A1per A=C5=BEman wrot= e: >>> >>> Nicol, >>> >>> I forsee a fight to distinguish the unary && from the binary && in fold >>>>> expressions, but otherwise... >>>>> >>>> I don't think there *is* an "otherwise" at that point. If &&... >>>> already has a meaning, that's the end of the conversation. Backwards >>>> incompatible changes for this are probably a non-starter. >>>> >>> >>> The "otherwise" was not meant as "I see a possibility of changing the >>> meaning of existing syntax" :). I meant that (args&&)... might actually >>> still be possible. I do think it's iffy. >>> >> >> What the problem might be? >> >> auto c =3D a&& && b; >> >> template >> auto sum(T&&... args) { >> return (args&& && ... && T{}); >> } >> >> These will do what it's expected. They look a bit funny, but not *that* >> funny. >> >> >>> Everyone: >>> >>> I do think "forward" needs more love, and the intersection with move >>> might or might not make sense, I'm not decided at this point. Both side= s of >>> the debate are valid, imo, and it really depends on the final syntax fo= r *forward >>> *if extending it to move makes sense. >>> >> >> I am yet to hear any objections to merger outside the dropping of >> "exactly" in "know *exactly *what going on". >> That is tiny price to pay for the 4+1 pretty solid pros I have given, >> especially considering - *you have no decisions to make, based on that >> information*. >> >> And don't forget, you are an expert, you are using thins for 10 years, >> you feel at home and only annoyances stick up for you (with forward). >> But for a new user it is a different story. Essentially one less lesson >> to learn. >> >> >> >>> >>> In fact, if the '&&' unary postifx worked, then std::move would *not* b= e >>> covered by it, as &&-collapsing rules would have to be obeyed, and an >>> lvalue with a &&-specifier decays into a reference. (& && -> &) >>> >> >> I do not understand your point. What reference collapsing has to do with >> an operator? >> >> >>> >>> ... if this nips postfix && in the bud, I'm fine with that :). >>> >>> Also, I meant =3D> as prefix. Postfix unary operators are *weird*. >>> >> >> The problem will be as in [x=3D=3D>y] it will visually represent, well, >> exactly the opposite :) >> >> As for the postfix - they are the solution to the problem, for 4 reasons= .. >> >> 1. The highest possible precedence which is AWAYS what you want here. >> 2. Keep the clean the lhs clean to not visually confuse on assignment an= d >> keep the rhs "dirty" as img&&.flipped() or func&&(args&&=E2=80=A6)To nic= ely >> indicate "just before you make this call" notion >> 3. The are not common, so they do tend to draw attention. >> 4. The fact that the op is *after *the variable reinforces the reminder >> "this is end of line", "the variable was before me". I am ending it, do = not >> use after me. >> >> As you can see all 4 apply to both move and forward equally. That is >> because, the fact that it is and-of-line is more important then what was= in >> the train. >> It really is. >> >> >>> >>> G >>> >>> >>> >>> On Mon, May 28, 2018 at 6:40 PM, Nicol Bolas wrote: >>> >>>> On Monday, May 28, 2018 at 1:11:42 PM UTC-4, Ga=C5=A1per A=C5=BEman wr= ote: >>>>> >>>>> I forsee a fight to distinguish the unary && from the binary && in >>>>> fold expressions, but otherwise... >>>>> >>>> >>>> I don't think there *is* an "otherwise" at that point. If &&... >>>> already has a meaning, that's the end of the conversation. Backwards >>>> incompatible changes for this are probably a non-starter. >>>> >>>> Indeed, the problem of fold expressions with post-fix operators like >>>> this is going to crop up with a lot of possible operators. >>>> >>>> -- >>>> 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/isocpp.org/d/msgid/std-proposals/70fe7dc7-= b8a6-4498-9aa6-f88e6af06506%40isocpp.org >>>> >>>> . >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Group= s >> "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> 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/0c4f8aa4-6b= 4f-4fe3-a02a-ef33eae990a8%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/CALmDwq0Fzcx= OdmG2GtZRDO70X%3D1j9qEUnL-gqB66606vSU%3D_eQ%40mail.gmail.com > > . > --=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/CALvx3hYcWKh-_1t298oPx7xThDaHab5Dy354vzCwTdswBnM= JoA%40mail.gmail.com. --000000000000c08aac056d4b8fd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Anyone proposing adding another operator to c++ has clearl= y not recently had to teach the language or maintain code.

forward (or give, or similar) should be a keyword. I know the= committee fears adding keywords, but this fear is unfounded. The constant = hoop-jumping merely to avoid the inevitable simply creates technical debt w= hich will impede design choices in the future.


On Mon, 28 May= 2018 at 22:26, Nicolas Lesser <blitzrakete@gmail.com> wrote:
That postfix && is problematic:

<= div>auto Value =3D Arg && (Foo =3D=3D 10 || Foo =3D=3D 11);

Today this would evaluate Arg and iff true see if Foo is = 10 or 11 and store that value in Value.

What would= this code mean with your operator? Would it instead be interpreted as a fo= rwarded Arg called whether Foo is 10 or 11?
Would it be ambiguous= ? How do you want to disambiguate between the two meanings?

=
On Mon, May 28, 2018 at 10:20 P= M <mihailn= ajdenov@gmail.com> wrote:


On Monday, May 28, 2018 at 8:50:41 PM UTC+3, Ga=C5= =A1per A=C5=BEman wrote:
Nicol,

I forsee a fight to distinguish the unary && from = the binary && in fold expressions, but otherwise...
I don't think there=C2=A0is=C2=A0= an "otherwise" at that point. If &&... already has a mean= ing, that's the end of the conversation. Backwards incompatible changes= for this are probably a non-starter.

The "otherwise" was not meant as "I see a possibilit= y of changing the meaning of existing syntax" :). I meant that (args&a= mp;&)... might actually still be possible. I do think it's iffy.

What the problem might be?
<= div>
auto c =3D a&& && b;

template<class... T>
auto sum(T&&...= args) {
=C2=A0return (args&& && ... && T{});=C2= =A0
}
=C2=A0
These will do what it's expected. = They look a bit funny, but not that funny.=C2=A0


Everyone:

I do think "forward" needs = more love, and the intersection with move might or might not make sense, I&= #39;m not decided at this point. Both sides of the debate are valid, imo, a= nd it really depends on the final syntax for forward if extending it= to move makes sense.

I am yet = to hear any objections to merger outside the dropping of "exactly"= ; in "know exactly what going on".=C2=A0
That is= tiny price to pay for the 4+1 pretty solid pros I have given, especially c= onsidering - you have no decisions to make, based on that information.

And don't forget, you are an expert, you ar= e using thins for 10 years, you feel at home and only annoyances stick up f= or you (with forward).
But for a new user it is a different story= .. Essentially one less lesson to learn.=C2=A0

= =C2=A0
<= br>
In fact, if the '&&' unary postifx worked, th= en std::move would *not* be covered by it, as &&-collapsing rules w= ould have to be obeyed, and an lvalue with a &&-specifier decays in= to a reference. (& && -> &)

I do not understand your point. What reference collapsing h= as to do with an operator?
=C2=A0

... if this nips postfix= && in the bud, I'm fine with that :).

Also, I meant =3D> as prefix. Postfix unary operators are *weird*.

The problem will be as in [x=3D=3D&= gt;y] it will visually represent, well, exactly the opposite :)
<= br>
As for the postfix - they are the solution to the problem, fo= r 4 reasons.

1. The highest possible precedence wh= ich is AWAYS what you want here.=C2=A0
2. Keep the clean the lhs = clean to not visually confuse on assignment and keep the rhs "dirty&qu= ot; as img&&.flipped() = or func&&(args&&=E2=80= =A6)To nicely indicate "just before you make this call" no= tion
3. The are not common, so they do tend to draw attention.
4. The fact that the op is after the variable reinforces the= reminder "this is end of line", "the variable was before me= ". I am ending it, do not use after me.

As yo= u can see all 4 apply to both move and forward equally. That is because, th= e fact that it is and-of-line is more important then what was in the train.= =C2=A0
It really is.
=C2=A0

G



On Mon, May 28, = 2018 at 6:40 PM, Nicol Bolas <jmck= ....@gmail.com> wrote:
On Monday, May 28, 2018 at 1:11:42 PM UTC-4, Ga=C5=A1per = A=C5=BEman wrote:
I= forsee a fight to distinguish the unary && from the binary &&a= mp; in fold expressions, but otherwise...

=
I don't think there is an "otherwise" at t= hat point. If &&... already has a meaning, that's the end of th= e conversation. Backwards incompatible changes for this are probably a non-= starter.

Indeed, the problem of fold expressions w= ith post-fix operators like this is going to crop up with a lot of possible= operators.

--
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-proposa= ls/70fe7dc7-b8a6-4498-9aa6-f88e6af06506%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/0c4f8aa4-6b4f-= 4fe3-a02a-ef33eae990a8%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-p= roposals/CALmDwq0FzcxOdmG2GtZRDO70X%3D1j9qEUnL-gqB66606vSU%3D_eQ%40mail.gma= il.com.

--
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/CALvx3hYcWKh-_1t2= 98oPx7xThDaHab5Dy354vzCwTdswBnMJoA%40mail.gmail.com.
--000000000000c08aac056d4b8fd3-- .