220 31791 article Path: news.gmane.org!.POSTED!not-for-mail From: Casey Carter Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Number Concept Family Date: Mon, 27 Mar 2017 21:55:38 -0700 Lines: 643 Approved: news@gmane.org Message-ID: References: <50075dd2-ae2a-4022-8e94-196d44e34687@isocpp.org> <49308661-71b7-f4a1-b2b2-d5320f6b5372@wanadoo.fr> <96c8303e-2f0b-4658-9e4d-3baa0773c921@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114925826856c7054bc3455c X-Trace: blaine.gmane.org 1490676951 675 195.159.176.226 (28 Mar 2017 04:55:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 28 Mar 2017 04:55:51 +0000 (UTC) Cc: "ISO C++ Standard - Future Proposals" , Eric Niebler To: Christopher Di Bella Original-X-From: std-proposals+bncBAABBTOZ47DAKGQECT663EA@isocpp.org Tue Mar 28 06:55:45 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt0-f200.google.com ([209.85.216.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1csjAU-0007VI-2V for gclcip-std-proposals@m.gmane.org; Tue, 28 Mar 2017 06:55:42 +0200 Original-Received: by mail-qt0-f200.google.com with SMTP id 46sf47194097qtu.18 for ; Mon, 27 Mar 2017 21:55:48 -0700 (PDT) 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 :cc: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=sxOki4+FzU2bCeWo9J6APLA3+Qkjcz6ZtRsyY51835s=; b=OQuNdexbwHTwyUD0hJTPjMtwDpcI5+Q+iCd1YC2gUQHVuYrgKkmFe+4mFnMKERRIaG JiKLkjnwihakrov6bBgdFG9YihkZv+FazMGNYk3CR5T5LAjrB8wQ47BwLPx5Rw3ZtPLz iSAwYrRj6vSLbjppZNoMp8Voa4+ruLOvlhK7mG6W/ZDrvrOb803nKq3+Lf1kHTTxbkrg vmeI3uW9ngSet5tiAUWMphu3u1Um3t0Q3WM0WrPuP3lm82RFS2jR/6nQHrAGojTXxGWc nf9f3ti+/wsRkR3hvpr0TKEepalq1im2n3LyWmWyg37rVcYXHaZd5ZRSehEMe2YR9PyP FFvQ== 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:cc: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=sxOki4+FzU2bCeWo9J6APLA3+Qkjcz6ZtRsyY51835s=; b=J5VuB0G8vQAvO+D5bNdm/BfsMSYh600gvfc29w3ByNHpdso85WFYxuxfulANO9Bkoq 3E7aeim0TJBHjM5OvNzhFbeiWOqdF7Yn4nnNg3qEyR4fF0ECyYMbiq2qXfCIvDa1olJc NGQqchSuqEqgvmZcSIT4o9j5tQqMBezTAtnC8hpU7vdjpEVSfkuBkjDfKf1ZCK6uq/zk xtMTsYbrsVsrP5zKV71iUUAOZ8wd9i6oTsPjk/Pua77F4T0qQeCN0Pa7ZEy9VFslyy+1 YbbKLHp4TM1qKMbNUbyckpl+trpDX4lITaHKC9rqRadzMw6nXULhRJAPIlPC9bIHNwrc 6XsQ== X-Gm-Message-State: AFeK/H25pvaOtCojSNT2j2xhbvG37lz36rVxcojo8UEAgiG03OBPYKhr9gKjXsGySb5bSA== X-Received: by 10.237.36.165 with SMTP id t34mr8051976qtc.50.1490676942709; Mon, 27 Mar 2017 21:55:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.2.76 with SMTP id 73ls2245752itu.13.gmail; Mon, 27 Mar 2017 21:55:41 -0700 (PDT) X-Received: by 10.36.89.211 with SMTP id p202mr14218838itb.97.1490676941085; Mon, 27 Mar 2017 21:55:41 -0700 (PDT) Original-Received: from smtprelay.hostedemail.com (smtprelay0240.hostedemail.com. [216.40.44.240]) by mx.google.com with ESMTPS id t28si3080737ioe.54.2017.03.27.21.55.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 21:55:40 -0700 (PDT) Received-SPF: neutral (google.com: 216.40.44.240 is neither permitted nor denied by best guess record for domain of casey@carter.net) client-ip=216.40.44.240; Original-Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id 134E329DD78 for ; Tue, 28 Mar 2017 04:55:40 +0000 (UTC) X-Session-Marker: 4361736579404361727465722E6E6574 X-HE-Tag: beast93_88b3ef43ec827 X-Filterd-Recvd-Size: 41654 Original-Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com [209.85.161.176]) (Authenticated sender: Casey@Carter.net) by omf01.hostedemail.com (Postfix) with ESMTPA for ; Tue, 28 Mar 2017 04:55:39 +0000 (UTC) Original-Received: by mail-yw0-f176.google.com with SMTP id d191so45900478ywe.2 for ; Mon, 27 Mar 2017 21:55:39 -0700 (PDT) X-Received: by 10.129.124.214 with SMTP id x205mr19092764ywc.284.1490676938721; Mon, 27 Mar 2017 21:55:38 -0700 (PDT) Original-Received: by 10.37.20.131 with HTTP; Mon, 27 Mar 2017 21:55:38 -0700 (PDT) In-Reply-To: X-Gmail-Original-Message-ID: X-Original-Sender: casey@carter.net X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 216.40.44.240 is neither permitted nor denied by best guess record for domain of casey@carter.net) smtp.mailfrom=casey@carter.net 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:31791 Archived-At: --001a114925826856c7054bc3455c Content-Type: text/plain; charset=UTF-8 This proposal is critically missing a list of use cases, which naturally gives rise to the confusion in the discussion thread. Everyone everywhere is going to point out every example they can recall of a number-like thing that doesn't fit the proposed concepts, and none of us can ascertain which of those examples is or is not in scope. Concept(s) which try to satisfy everyone's notion of what a number should be will likely be so watered down as to be useless for any actual use cases. The other lack I see is that the presentation of the concepts is almost entirely syntactic. Lists of operations without meaning do not support equational reasoning, which is the entire point of having concepts. The major feature of e.g. CopyConstructible is not that the syntax "T a = b;" must be valid, it's that after that definition we are guaranteed that a is equal to b and b is unmodified. Without semantics, I don't know what these concepts *mean* so I cannot evaluate their utility. Confusion about uses is to a large extent unavoidable with a name as general as Number. I urge you to maintain focus by enumerating a set of use cases, algorithms and/or classes that require Numbers, and using a characterization of their requirements to define your concepts. From that seed, you can develop the concepts organically by gradually growing the set of use cases the concepts can constrain and/or finding the boundaries that require you to add new concepts to cover additional use cases without over-diluting the existing concepts. On Mon, Mar 27, 2017 at 1:25 PM, Christopher Di Bella wrote: > Lots of great feedback so far :) > I apologise if I miss your contributions: I've got a lot to work with. > Please don't be shy to raise a point twice. > > > No. It's required to be a "signed integer type", which plain char isn't > regardless of representation > > Thanks for the clarification :) > > > So we couldn't have an unsigned Number of 8 bits, at least not a builtin > one :( > > Both signed char and unsigned char are permitted, which means that int8_t > and uint8_t are allowed :) > > > And it depends how "mathy" we want to get. When I see OrderedNumber, I > think "ordinal". ie 1st 2nd 3rd instead of 1 2 3. > > > > An ordinal would/should have a ++ ("successor") and += would be like > std::advance(). But it wouldn't be operator+=(Ordinal ord), it would be > operator+=(int amount) - ie give me the 5th ordinal after this one. > > > > ie if doubles were Ordinals ++ would/should give you the _next_ double. > Just like an iterator does. > > > > I'm not saying we want Ordinals; I'm saying we need to think carefully. > > I'm fielding a name new name for Number: > > s/Number/BasicNumber/ > s/OrderedNumber/Number/ > > Thoughts? Until I get some feedback on this, Number still refers to the > base concept. > Ordinals haven't been considered at all. > > > It is weird to have += on a type and don't have increment. > > It is weird. > > I thought so too, but types such as complex don't support operator++, > etc., which is why I moved it, along with StrictTotallyOrdered out of > Number. I think the trick here is to work out what a "Number" really should > be, and not to let types such as complex or N3352's cardinal dictate the > requirements. > > > I'm not an expert, but I believe that it has a sens only for integer > numbers. I was wondering just why this operation is not considered in your > classification, while you consider bitwise operations. > > This is a good point: it's the only mathematical operator missing, but I > can't think of a good way to include it. Definitely open to suggestions. > > > I was thinking of safe numbers > > > > safe * safe -> safe > > > > or fixed point numbers (as proposed by L. Crowl in n3352). > > > > or bounded::integer ( http://doublewise.net/c++/bounded/) > > > > Which kind of Numbers would be those? > > > As an exercise, one might try to apply the "Number Concept" to the > > variety of "numbers" we've already been working with in our real code. > > I think the utility would be limited. > > I'm currently working with bounded::integer and the Boost-proposed > safe. I've also emailed Lawrence to find out if there's a prototype > for N3352, so I can toy with that. > I'll look for some other numbers to toy with and report back. The critical > key here is to produce real-world examples, not just contrived examples. > > > Could there be a concept for types which do not wrap around on > overflow? When you add 1 to a signed type, it should always be greater. > That's a very valuable property which does not extend to unsigned types. > > Only if we can syntactically assert this, but this feels like a property > of a concept, rather than a concept itself. I'd need to see more to be > convinced either way, but I am definitely erring on the side of property. > > > It's not just many of the types being considered for a Numerics TS > which would fail Number. Consider dimensional analysis types such as those > in Boost.Units. Returning novel types is very useful but is commonly > overlooked. > > Perhaps what are being described here are types which can replace > fundamental scalar types under certain circumstances. > > > > This is certainly an interesting paper, but Number etc. seem to be on > > the exclusive side. I've no idea whether this is a good idea or not. > > > I'm in agreement with this sentiment. I'm not really understanding what > > this would be used for and why it would be helpful. We use the word > > "Number" (and by implication the concept of "Number") in a variety of > > ways which sometimes from conflict. > > I will confess that the only types that I've considered are fundamentals > and types that mimic fundamentals. It never even occurred to me that there > might be other ways to represent a number. The implicit motivation (based > off my actions, not words) is for an algorithm or type to be allowed to > accept any type that can be used like an integer or floating-point and use > it as such. I'm not even sure I consciously was aware of this while > writing. This will likely go back to the case study suggested above. > > > BTW, for Regular Numbers I will request N{1} and require the identity > axioms for +,N{0} and *,N{1}. > > N{1} would be the same as N{0}, since it's constructing N from an > int-literal. How would this be semantically different to N{0}? > I do like where you're going with these though, so if there's an > number-r2.pdf, they'll be in there as textual semantic requirements. > > > I want Ordinals... rest of email > > Interesting ideas there :) > > > >> Also, Number seems to exclude integers shorter than `int` because it > expects results of binary arithmetic to be `common_type_t` whereas the > result of some integer arithmetic operations is promoted to `int`. > > Right. builtin short is already in line with my example > > short + short => int > > Hmm... I wasn't aware of this, but Number is definitely valid for > all fundamentals T and U, at least on GCC. Won't know anything else until > Clang or MSVC implement Concepts too. This failing would be a > non-starter/staller. > > > No. duration would fall on the 1-dimensinal quantity. The > operations are not the same as those of a Number. Note that some of the > operations, e.g. *,/ and % can > take a Regular Number on the rhs > parameter. However, the Rep parameter must be a Regular Number. > > I think that's what John means: > template > class duration; > > That's definitely something I'd like to see it used for. > > > I would characterise this idea of one of "premature conceptualization" > > Possibly! > > > > Please let me know if I missed something that you'd like addressed! > > Cheers, > > Chris > > On Mon, 27 Mar 2017 at 10:39 T. C. wrote: > > > > On Sunday, March 26, 2017 at 5:04:19 PM UTC-4, Nicol Bolas wrote: > > On Sunday, March 26, 2017 at 4:05:43 PM UTC-4, Christopher Di Bella wrote: > > > Why char types are not considered as Numbers? isn't int8_t a Number? > > int8_t is a signed integral; it should be a signed char^, which is a > distinct type from char. char is not a Number, it is a character type that > is also an arithmetic type, but signed char is a Number. Number is > not intended to be a super-set of arithmetic types. > > ^It's strictly implementation-defined, but I don't think it can be a char > either way? > > > It could be `char` if the implementation makes `char` an 8-bit signed, > two's complement integer. So you cannot assume that it isn't `char`. > > > No. It's required to be a "signed integer type", which plain char isn't > regardless of representation. See [basic.fundamental]/2, C11 6.2.5/4, > 7.20.1.1/1. > > -- > 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/96c8303e-2f0b-4658- > 9e4d-3baa0773c921%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/CAJw-yXng2XEBGPcBXabWTgaVeuVFQ13a23j81XLGyjOv5TLWFA%40mail.gmail.com. --001a114925826856c7054bc3455c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This proposal is critically missing a list of use cases, w= hich naturally gives rise to the confusion in the discussion thread. Everyo= ne everywhere is going to point out every example they can recall of a numb= er-like thing that doesn't fit the proposed concepts, and none of us ca= n ascertain which of those examples is or is not in scope. Concept(s) which= try to satisfy everyone's notion of what a number should be will likel= y be so watered down as to be useless for any actual use cases.

The other lack I see is that the presentation of the concepts is al= most entirely syntactic. Lists of operations without meaning do not support= equational reasoning, which is the entire point of having concepts. The ma= jor feature of e.g. CopyConstructible is not that the syntax "T a =3D = b;" must be valid, it's that after that definition we are guarante= ed that a is equal to b and b is unmodified. Without semantics, I don't= know what these concepts *mean* so I cannot evaluate their utility.
<= div>
Confusion about uses is to a large extent unavoidable wi= th a name as general as Number. I urge you to maintain focus by enumerating= a set of use cases, algorithms and/or classes that require Numbers, and us= ing a characterization of their requirements to define your concepts. From = that seed, you can develop the concepts organically by gradually growing th= e set of use cases the concepts can constrain and/or finding the boundaries= that require you to add new concepts to cover additional use cases without= over-diluting the existing concepts.

On Mon, Mar 27, 2017 at 1:25 PM, Christophe= r Di Bella <cjdb.ns@gmail.com> wrote:
Lots of great feedback so far :)
I apologise if I miss your contribution= s: I've got a lot to work with. Please don't be shy to raise a poin= t twice.

>=C2=A0No. It's required to be a "signed integ= er type", which plain char isn't regardless of representation

Thanks for the clarification :)=

> So we couldn't have an unsigned Number of 8 bits, at = least not a builtin one :(=C2=A0=C2=A0

Both signed char and unsigned char are permitt= ed, which means that int8_t and uint8_t are allowed :)

> And it depends how "mathy"= we want to get.=C2=A0 When I see OrderedNumber, I think "ordinal"= ;.=C2=A0 ie 1st 2nd 3rd instead of 1 2 3.
>
> An ordinal would/should have a ++ ("success= or") and +=3D would be like std::advance().=C2=A0 But it wouldn't = be operator+=3D(Ordinal ord), it would be operator+=3D(int amount) - ie giv= e me the 5th ordinal after this one.
>
> ie if doubles were Ordinals ++ would/should give you = the _next_ double.=C2=A0 Just like an iterator does.
>
> I'm not saying we want Ordinals; = I'm saying we need to think carefully.

=
I'm fielding a name new name for Number:

s/Number/BasicNumber/
s/OrderedNumber/Number/

Thoughts? Until I get some feedba= ck on this, Number still refers to the base concept.
Ordinals haven't been considered = at all.

>=C2=A0It is weird to have +=3D on a type and don= 9;t have increment.
>=C2=A0It is weird.

<= /span>
I thou= ght so too, but types such as complex don't support operator++, etc., w= hich is why I moved it, along with StrictTotallyOrdered out of Number. I th= ink the trick here is to work out what a "Number" really should b= e, and not to let types such as complex or N3352's cardinal dictate the= requirements.
<= div dir=3D"ltr" class=3D"m_5372834400144640337gmail_msg">

&= gt;=C2=A0I'm not an expert, but I believe that it has a sens only for= integer numbers. I=C2=A0 was wondering just why this operation is not cons= idered in your classification, while you consider bitwise operations.

This is a good point: it&= #39;s the only mathematical operator missing, but I can't think of a go= od way to include it. Definitely open to suggestions.

>=C2=A0I was thinking of safe nu= mbers=C2=A0
=
>
> = =C2=A0 =C2=A0safe<short> * safe<short> -> safe<int>
>
> or fixed point numbers (as proposed by L. Crowl in n3352).
>
> or bounded::integer (= =C2=A0http://doublewise.net/c+= +/bounded/)
>
> Which kind of Numbers would be tho= se?
<= br>
<= div class=3D"m_5372834400144640337gmail_msg">>=C2=A0As an exercise, one might try to apply the "Number Conce= pt" to the
> variety of "numbers" we've already been working with= in our real code.
> I think the utility would be limited.=C2=A0=C2= =A0

I'm curre= ntly working with bounded::integer and the Boost-proposed safe<int>. = I've also emailed Lawrence to find out if there's a prototype for N= 3352, so I can toy with that.
I'll look for some other numbers to toy with and report back. T= he critical key here is to produce real-world examples, not just contrived = examples.

>=C2=A0Could the= re be a concept for types which do not wrap around on overflow? When you ad= d 1 to a signed type, it should always be greater. That's a very valuab= le property which does not extend to unsigned types.

Onl= y if we can syntactically assert this, but this feels like a property of a = concept, rather than a concept itself. I'd need to see more to be convi= nced either way, but I am definitely erring on the side of property.=

> <= /span>It's not just = many of the types being considered for a Numerics TS which would fail Numbe= r. Consider dimensional analysis types such as those in Boost.Units. Return= ing novel types is very useful but is commonly overlooked.
>=C2=A0Perhaps what are being described here are types which c= an replace fundamental scalar types under certain circumstances.


> This is certainl= y an interesting paper, but Number etc. seem to be on
> the exclusive side. I've no idea whether th= is is a good idea or not.

> I'm in agreement with this sentim= ent.=C2=A0 I'm not really understanding what
> this would be used for and why it would be helpful.= =C2=A0 We use the word
> &qu= ot;Number" (and by implication the concept of "Number") in a= variety of
> ways which som= etimes from conflict.

I will confess that the only types that I've con= sidered are fundamentals and types that mimic fundamentals. It never even o= ccurred to me that there might be other ways to represent a number. The imp= licit motivation (based off my actions, not words) is for an algorithm or t= ype to be allowed to accept any type that can be used like an integer or fl= oating-point and use it as such. I'm not even sure I consciously was aw= are of this while writing. This will likely go back to the case study sugge= sted above.

>=C2=A0BTW, for Regular Numbers I will request N{1} and require the i= dentity axioms for +,N{0} and *,N{1}.
N{1} would be the same as N{0}, since i= t's constructing N from an int-literal. How would this be semantically = different to N{0}?
I do like where you're going with= these though, so if there's an number-r2.pdf, they'll be in there = as textual semantic requirements.

>=C2=A0I wan= t Ordinals... rest of email

Interesting ideas there :)


>> Also, Number seems to exclude integers shorter than= `int` because it expects results of binary arithmetic to be `common_type_t= ` whereas the result of some integer arithmetic operations is promoted to `= int`.
> Right. builtin short is already in line with my example
&= gt; short + short =3D> int

Hmm... I wasn't aware of this, but Number<T, U>= is definitely valid for all fundamentals T and U, at least on GCC. Won'= ;t know anything else until Clang or MSVC implement Concepts too. This fail= ing would be a non-starter/staller.

>=C2=A0No. duration<Rep, Period> would fall on the 1-d= imensinal quantity. The operations are not the same as those of a Number. N= ote that some of the operations, e.g. *,/ and % can > take a Regular Num= ber on the rhs parameter. However, the Rep parameter must be a Regular Numb= er.=C2=A0=C2=A0

I think that's what John means:
template <RegularNumber Rep, typenam= e Period>
class duration;

That's def= initely something I'd like to see it used for.

>=C2=A0I would characterise this idea of one of &q= uot;premature conceptualization"
Possibly!



P= lease let me know if I missed something that you'd like addressed!

Cheers,

Chris
<= div dir=3D"ltr" class=3D"m_5372834400144640337gmail_msg">
On Mon, 27 Mar 2017 at 10:39 T. C. <= rs2740@gmail.com> wrote:


On Sunday, March 26, 2017 at 5:04:19 PM UTC-4, N= icol Bolas wrote:
On S= unday, March 26, 2017 at 4:05:43 PM UTC-4, Christopher Di Bella wrote:
> Why= char types are not considered as Numbers? isn't int8_t a Number?

int8_t is a si= gned integral; it should be a signed char^, which is a distinct type from c= har. char is not a Number, it is a character type that is also an arithmeti= c type, but signed char is a Number. Number is not=C2=A0intended to be a su= per-set of arithmetic types.

^It's strictly implementation-defined, but I= don't think it can be a char either way?

It could be `= char` if the implementation makes `char` an 8-bit signed, two's complem= ent integer. So you cannot assume that it isn't `char`.

No. It's required to be a "sig= ned integer type", which plain char isn't regardless of representa= tion. See [basic.fundamental]/2, C11 6.2.5/4, 7.20.1.1/1.=

--
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@<= wbr>isocpp.org.
To post to this group, send email to std-propos= als@isocpp.org.
 To view this discussion on the web visit https://groups.google.com/a/i= socpp.org/d/msgid/std-proposals/96c8303e-2f0b-4658-9e4d-3baa0773c= 921%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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJw-yXng2XEBGPcB= XabWTgaVeuVFQ13a23j81XLGyjOv5TLWFA%40mail.gmail.com.
--001a114925826856c7054bc3455c-- .