220 32549 <2798d4f2-09b1-4030-965d-0bbb36a5549b@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: ma.kalbfuss@web.de Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: relaxing rules for ternary operator. Allow incompatible types. Date: Sun, 21 May 2017 07:11:13 -0700 (PDT) Lines: 738 Approved: news@gmane.org Message-ID: <2798d4f2-09b1-4030-965d-0bbb36a5549b@isocpp.org> References: <1b5ee8eb-53df-4e98-af2f-829c7bc2e5b2@isocpp.org> <9064929.QEV8q21eIZ@tjmaciei-mobl1> <99350a9e-0c6b-468d-9761-f2b2b052275e@isocpp.org> <795341bd-d042-49c9-9eba-6b8ac6ca8a5e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2087_1742423123.1495375873967" X-Trace: blaine.gmane.org 1495375875 22774 195.159.176.226 (21 May 2017 14:11:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 21 May 2017 14:11:15 +0000 (UTC) Cc: ma.kalbfuss@web.de To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC7YTI72XQOBBAWAQ3EQKGQEVS2WCPA@isocpp.org Sun May 21 16:11:10 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f198.google.com ([209.85.213.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dCRZd-0005nZ-P4 for gclcip-std-proposals@m.gmane.org; Sun, 21 May 2017 16:11:10 +0200 Original-Received: by mail-yb0-f198.google.com with SMTP id 130sf12653436ybl.7 for ; Sun, 21 May 2017 07:11: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=MgtklsRYpYizKAQE6Y8MiBlyjDcE5caU9ucdjc7qaKk=; b=MmeLdTavW/DneybxTdwvqHLnr2fCvtmNt0Ide7DdQrhbxUL95XADc2APDv2zat/rpm lPp4sjyU2pcavxLOxAJzcv11k0Ux+8szoa/g+ZozpU3ereHL7Q/6NJ0gbnx6BW1T75mQ H9g703hbYrxrSiOcthovs6FsKPBBvCobYQlpWvA4ercRHeTjqglkEfxyZiEesLPZ/p+D 2iLyisi4S89aBJ+SEh3VsYX0vqCx29zl5ne9obgFZyWgcEONJ6jszvnY5J4BKifCjWU1 97G2lc+tf7ZdBA/iU8rK1dNqzO7TcxZ2TxOZuNhINAktxO8ZG0JlLRU0oN96Ka1rSfCb WXtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=MgtklsRYpYizKAQE6Y8MiBlyjDcE5caU9ucdjc7qaKk=; b=omoXJbY8NkWhFNNTOS1bxxe+8KJLVsF65xeJi6rc3htqkAtz5vI352KXfX1ktT/TvG 2moRqG9uQdHRgkKrMoQFvCzkHNSWZ7m7AlfDIyzO2WHA67BwjX6KAVh4C1meLwNE/7K+ LoLFNLj/Bwoyz++5J3wrIFZqyS7A0pIyJEAVFGTeL1j0EOfiBYSjFAouWyQWbeNf2qh7 dv+P6eIjnDmWgklDlAdILJ5fuG58exGfUk41Yf65V59kQzBHJfMnm8ck3NkMpSwxjE4V NbcIvW1JhvM66PBB0jLWY5Ux6eRkerXNf1pgOnvu9lz4a0kr1R+n8fAvPPxD4uRMBVEx 4GJw== X-Gm-Message-State: AODbwcAPSO/bARrcDbEC1Ir+1T0LiW8ABtnCY66GXDxN5rLPvyjbXfVt Ym2x1e0iSDReqTVT X-Received: by 10.129.160.196 with SMTP id x187mr9203418ywg.90.1495375875221; Sun, 21 May 2017 07:11:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.45.193 with SMTP id g59ls2104768otb.40.gmail; Sun, 21 May 2017 07:11:14 -0700 (PDT) X-Received: by 10.157.17.23 with SMTP id g23mr390652ote.4.1495375874425; Sun, 21 May 2017 07:11:14 -0700 (PDT) In-Reply-To: <795341bd-d042-49c9-9eba-6b8ac6ca8a5e@isocpp.org> X-Original-Sender: ma.kalbfuss@web.de 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:32549 Archived-At: ------=_Part_2087_1742423123.1495375873967 Content-Type: multipart/alternative; boundary="----=_Part_2088_776051707.1495375873969" ------=_Part_2088_776051707.1495375873969 Content-Type: text/plain; charset="UTF-8" The following code should be generated when a loop is involved. the loop has its own scope. The code duplication is limited to the scope of the loop. But let's improve it further. Instead of duplicate the following code in the enclosing scope, it is sufficient to duplicate the dependend code. Code is dependend if the result of the ternary operation is involved. So only these parst are duplicated. As an addition, the code is only duplicated, if the condition is known at runtime. If it is known at compile time, only one branch is created. Code outside of the loop or the code necessary to implement the loop is NOT duplicated and is not part of the branches. For now, I will call this construct "generic ternary operator". Like other generics it introduces code duplication. It's not a special problem of this construct. It is important, that existing code does not break. For cases where the existing conversion rules apply, there should be no duplication. Exmaple including a loop: struct A{ void doit(){ } }; struct B{ void doit(){ } }; int main() { auto runtime_condition = true; for(int i = 0; i < 100; i++) { auto x = runtime_condition ? A{} : B{}; x.doit(); /* do something without x */ x.doit() /* do something without x */ } return 0; } struct A{ void doit(){ } }; struct B{ void doit(){ } }; int main() { auto runtime_condition = true; for(int i = 0; i < 100; i++) { if(runtime_condition) goto ternary_branch_1; else goto ternary_branch_2; ternary_branch_1: A __instance1__; __instance1__.doit(); goto ternary_end_1; ternary_branch_2: B __instance2__; __instance2__.doit(); ternary_end_1: /* do something without x */; ternary_branch_3: __instance1__.doit(); goto ternary_end_2; ternary_branch_4: __instance2__.doit(); ternary_end_2: /* do something without x */; } return 0; } A::doit(): push rbp mov rbp, rsp mov QWORD PTR [rbp-8], rdi nop pop rbp ret B::doit(): push rbp mov rbp, rsp mov QWORD PTR [rbp-8], rdi nop pop rbp ret main: push rbp mov rbp, rsp sub rsp, 16 mov BYTE PTR [rbp-5], 1 mov DWORD PTR [rbp-4], 0 ..L11: cmp DWORD PTR [rbp-4], 99 jg .L4 cmp BYTE PTR [rbp-5], 0 je .L13 nop lea rax, [rbp-6] mov rdi, rax call A::doit() jmp .L9 ..L13: nop lea rax, [rbp-7] mov rdi, rax call B::doit() ..L9: lea rax, [rbp-6] mov rdi, rax call A::doit() nop add DWORD PTR [rbp-4], 1 jmp .L11 ..L4: mov eax, 0 leave ret Am Sonntag, 21. Mai 2017 15:00:03 UTC+2 schrieb Mingxin Wang: > > You may as well consider the following situations: > > *Loops* > > It is difficult for compilers to generate code for loops with the feature > you proposed, e.g.: > > void foo(int n) { > /* A: Do something before the loop */ > for (int i = 0; i < n; ++i) { > /* B: Do something */ > auto x = runtime_condition() ? A{} : B{}; > /* C: Do some other things with x */ > } > /* D: Do something after the loop */ > } > *Code Snippet 1* > > As far as I am concerned, here is the equivalent of the code that the > compiler would automatically generate for the code above (with your method): > > template > void bar(int i, int n, T x) { > /* C: Do some other things with x */ > ++i; > if (i < n) { > /* B: Do something */ > if (runtime_condition()) { > bar(i, n, A{}); > } else { > bar(i, n, B{}); > } > } > } > > void foo(int n) { > /* A: Do something before the loop */ > if (0 < n) { > /* B: Do something */ > if (runtime_condition()) { > bar(1, n, A{}); > } else { > bar(1, n, B{}); > } > } > /* D: Do something after the loop */ > } > *Code Snippet 2* > > It is too complicated! Moreover, as the recursive call of the "function > template bar" is not able to be optimized, it will possibly increase the > runtime overhead. > > *Size* > > Compilers may generate a lot of redundant code when the feature is used > extensively, e.g.: > > auto x0 = runtime_condition_0() ? A0{} : B0{}; > auto x1 = runtime_condition_1() ? A1{} : B1{}; > // ... > auto xn = runtime_condition_n() ? An{} : Bn{}; > *Code Snippet 3* > > As you introduced, the compiler is supposed to generate code for every > path! For the code above, it requires O(2^n) size for code generation, > which is NOT acceptable in most cases. > > In fact, the challenges above can be solved gracefully with the "proxies" > and the "wrappers". > > As the condition is determined at runtime, the concrete type cannot be > deduced at compile time. The only reason for us to save the returned value > is that *they have similar expressions and semantics*. We can simply > extract the common expressions of the types which are used in the context > to a "proxy", and save the returned value with a "wrapper", e.g. Code > Snippet 1 can be reconstructed as is shown below (with better performance > and smaller size): > > /* Declares the common expressions required in the context */ > proxy P { > void f_0(); > double f_1(int, int); > }; > > void foo(int n) { > /* A: Do something before the loop */ > for (int i = 0; i < n; ++i) { > /* B: Do something */ > Wrapper

x(runtime_condition() ? Wrapper

(A{}) : Wrapper

(B{})); > P p = x.get_proxy(); > /* C: Do some other things with p */ > } > /* D: Do something after the loop */ > } > *Code Snippet 4* > > Mingxin Wang > -- 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/2798d4f2-09b1-4030-965d-0bbb36a5549b%40isocpp.org. ------=_Part_2088_776051707.1495375873969 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The following code should be generated when a loop is invo= lved. the loop has its own scope. The code duplication is limited to the sc= ope of the loop.
But let's improve it further. Instead of duplicate = the following code in the enclosing scope, it is sufficient to duplicate th= e dependend code.
Code is dependend=C2=A0 if the result of the ternary o= peration is involved. So only these parst are duplicated. As an addition, t= he code is only duplicated,
if the condition is known at runtime. If it = is known at compile time, only one branch is created. Code outside of the l= oop or the code necessary to
implement the loop is NOT duplicated and is= not part of the branches. For now, I will call this construct "generi= c ternary operator". Like other generics
it introduces code duplica= tion. It's not a special problem of this construct.
It is important,= that existing code does not break. For cases where the existing conversion= rules apply, there should be no duplication.

Exmaple including a lo= op:

<= /span>struct A{ void doit(){ } = };<= span style=3D"color: #000;" class=3D"styled-by-prettify">
struct B{ void doit(){ } };

int main()
{
=C2=A0 =C2=A0 auto runtime_condition =3D true;

=C2=A0= =C2=A0 fo= r(<= span style=3D"color: #008;" class=3D"styled-by-prettify">int i =3D 0; i < 100; i++) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto x =3D runtime_condition ? A{} := B{};
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = x.<= span style=3D"color: #000;" class=3D"styled-by-prettify">doit();
=C2=A0 =C2=A0 =C2=A0 =C2=A0= /* do som= ething without x */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 x.doit()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* do something without x */
=C2=A0 =C2=A0 = }

=C2=A0 =C2=A0 return<= span style=3D"color: #000;" class=3D"styled-by-prettify"> 0;
}



=
struct A{ void doit(){ } };
struct B{ void doit= (){ } };

int main()
{
= =C2=A0 =C2=A0 auto r= untime_condition =3D= true;

=C2=A0 =C2=A0 for(int i =3D 0; = i < 100; i++) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if(runtime_condition)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 goto ternary_branch_1;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 else
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 goto ternary_branch_2;

ternary_branch_1:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A __instance1__;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = __instance1__.doit();
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 goto t= ernary_end_1;
ter= nary_branch_2:
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 B __instance2__;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __instance2__.doit();
ternary_end_1: =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 /* do something without x */;
ternary_branch_3:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __instance1__.doit();
=C2=A0 =C2=A0 =C2=A0 =C2=A0 goto ternary_end_2;
ternary_branch_4<= span style=3D"color: #660;" class=3D"styled-by-prettify">:
=C2=A0 =C2=A0 =C2=A0 = =C2=A0__instance2__.= doit();
ternary_e= nd_2:
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 /* do something without x */;
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 return 0;}<= /div>




A::doit():
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 push =C2=A0 =C2=A0rbp
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 mov =C2=A0 =C2=A0 rbp, rsp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mov =C2=A0 =C2=A0 QWORD PTR [rbp-8], rdi
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nop
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 pop =C2=A0 =C2=A0 rbp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret<= br>B::doit():
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 push =C2=A0 =C2=A0rbp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mov =C2=A0 =C2= =A0 rbp, rsp
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 mov =C2=A0 =C2=A0 QWORD PTR [rbp-8], rdi
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nop
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pop= =C2=A0 =C2=A0 rbp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret
main:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 p= ush =C2=A0 =C2=A0rbp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mov =C2=A0 =C2=A0 rbp, rsp
=C2=A0 =C2=A0= =C2=A0 =C2=A0 sub = =C2=A0 =C2=A0 rsp, <= /span>16
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 mov =C2=A0 =C2=A0 BYTE PTR [rbp-5]= , <= span style=3D"color: #066;" class=3D"styled-by-prettify">1
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 mov =C2=A0 =C2=A0 DWORD PTR [rbp-= 4],= 0
.L11:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cmp =C2=A0 =C2=A0 DWORD PTR [rbp-4], 99=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 jg =C2=A0 =C2=A0 =C2=A0.L4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cmp= =C2=A0 =C2=A0 BYTE PTR [rbp-<= /span>5], 0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 je =C2=A0 =C2= =A0 =C2=A0= ..L13
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 nop
=C2=A0 =C2=A0 =C2=A0 =C2=A0 lea =C2=A0 = =C2=A0 rax= , <= span style=3D"color: #660;" class=3D"styled-by-prettify">[rbp-6]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mov =C2=A0 =C2=A0 rdi= , rax
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 call =C2=A0 =C2=A0A::doit()=C2=A0 =C2=A0 =C2=A0 =C2=A0 jmp =C2=A0 =C2=A0 .L9
.L13:=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nop
=C2=A0 =C2=A0 =C2=A0 =C2=A0 lea =C2= =A0 =C2=A0 rax, [rbp-7]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mov =C2=A0 =C2=A0 rdi, rax
=C2=A0 =C2=A0= =C2=A0 =C2=A0 call =C2=A0 =C2=A0B::doit()
.L9:
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 lea =C2=A0 =C2=A0 rax, [rbp-6]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mov =C2=A0 =C2= =A0 rdi, rax
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 call =C2=A0 =C2=A0A::doit()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nop
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 add =C2=A0 =C2=A0 DWORD PTR [rbp-4= ],<= span style=3D"color: #000;" class=3D"styled-by-prettify"> 1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 jmp = =C2=A0 =C2=A0 .L11.= L4:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mo= v =C2=A0 =C2=A0 eax,= 0<= span style=3D"color: #000;" class=3D"styled-by-prettify">
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 leave
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret
<= /div>







Am Sonntag, 21. Mai 2017 15:00:03 UTC+= 2 schrieb Mingxin Wang:
You may as well consider the f= ollowing situations:
Loops

<= /div>
It is difficult for compilers= to generate code for loops with the feature you proposed, e.g.:

void foo(int n) {<= /div>
=C2=A0 /* A: Do something before the loop */
=C2=A0 for= (int i =3D 0; i < n; ++i) {
=C2=A0 =C2=A0 /* B: Do something = */
=C2=A0 =C2=A0 auto x =3D runtime_condition() ? A{} : B{};
=C2=A0 =C2=A0 /* C: Do some other things with x */
=C2=A0 }=
=C2=A0 /* D: Do something after the loop */
}
Code Snippet 1

As far as I am concerned, here is the equivalent of= the code that the compiler would automatically generate for the code above= (with your method):

=
=
template <class T>
void bar(int i, int n, T x) {
=
=C2=A0 /* C: Do some other things with x */
=C2=A0 ++i;
=C2=A0 if (i < n) {
=C2=A0 =C2=A0 /* B: Do something */<= /div>
=C2=A0 =C2=A0 if (runtime_condition()) {
=C2=A0 =C2=A0 = =C2=A0 bar(i, n, A{});
=C2=A0 =C2=A0 } else {
=C2=A0 = =C2=A0 =C2=A0 bar(i, n, B{});
=C2=A0 =C2=A0 }
=C2=A0 }<= /div>
}

void foo(int n) {
=C2=A0 /* = A: Do something before the loop */
=C2=A0 if (0 < n) {
=C2=A0 =C2=A0 /* B: Do something */
=C2=A0 =C2=A0 if (runtime_= condition()) {
=C2=A0 =C2=A0 =C2=A0 bar(1, n, A{});
=C2= =A0 =C2=A0 } else {
=C2=A0 =C2=A0 =C2=A0 bar(1, n, B{});
=C2=A0 =C2=A0 }
=C2=A0 }
=C2=A0 /* D: Do something af= ter the loop */
}
Code Snippet 2=

It is too complicated! Moreover, as the recursive call = of the "function template bar" is not able to be optimized, it wi= ll possibly increase the runtime overhead.

Size

Compilers may generate a lot of redu= ndant code when the feature is used extensively, e.g.:

auto x0 =3D runtime_= condition_0() ? A0{} : B0{};
auto x1 =3D runtime_condition_1() ? = A1{} : B1{};
// ...
auto xn =3D runtime_condition_n() ?= An{} : Bn{};
C= ode Snippet 3

As you introduced, the compiler = is supposed to generate code for every path! For the code above, it require= s O(2^n) size for code generation, which is NOT acceptable in most cases.

In fact, the challenges above can be solved gracefu= lly with the "proxies" and the "wrappers".
As the condition is determined at runtime, the concrete type c= annot be deduced at compile time. The only reason for us to save the return= ed value is that they have similar expressions and semantics. We can= simply extract the common expressions of the types which are used in the c= ontext to a "proxy", and save the returned value with a "wra= pper", e.g. Code Snippet 1 can be reconstructed as is shown below (wit= h better performance and smaller size):

/* Declares the common expression= s required in the context */
proxy P {
=C2=A0 void f_0(= );
=C2=A0 double f_1(int, int);
};

=
void foo(int n) {
=C2=A0 /* A: Do something before the loop = */
=C2=A0 for (int i =3D 0; i < n; ++i) {
=C2=A0 =C2= =A0 /* B: Do something */
=C2=A0 =C2=A0 Wrapper<P> x(runtim= e_condition() ? Wrapper<P>(A{}) : Wrapper<P>(B{}));
= =C2=A0 =C2=A0 P p =3D x.get_proxy();
=C2=A0 =C2=A0 /* C: Do some = other things with p */
=C2=A0 }
=C2=A0 /* D: Do somethi= ng after the loop */
}
Code Snippet 4<= /font>

Mingxin Wang

--
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/2798d4f2-09b1-4030-965d-0bbb36a5549b= %40isocpp.org.
------=_Part_2088_776051707.1495375873969-- ------=_Part_2087_1742423123.1495375873967-- .