220 20521 article Path: news.gmane.org!not-for-mail From: Andrew Tomazos Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Rough Draft Proposal of Interpolated String Literals Date: Sun, 20 Sep 2015 15:01:26 +0200 Lines: 605 Approved: news@gmane.org Message-ID: References: <55FC8A6B.1070100@gmail.com> <650f78b0-289e-4880-9c03-8615b25360ec@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0103009cd7c95505202d5c1d X-Trace: ger.gmane.org 1442754091 15518 80.91.229.3 (20 Sep 2015 13:01:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Sep 2015 13:01:31 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBD5KHQXXWYPRBJ647KXQKGQE5HMIHTA@isocpp.org Sun Sep 20 15:01:30 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f197.google.com ([209.85.212.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZdeFF-0002zu-0Z for gclcip-std-proposals@m.gmane.org; Sun, 20 Sep 2015 15:01:29 +0200 Original-Received: by wisv5 with SMTP id v5sf23173785wis.0 for ; Sun, 20 Sep 2015 06:01:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type: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=0/bXbRxMlouxVUarFI46inHbMK9469QVn8iqYL+zsv8=; b=Ady+HrorHGLzsMCSAwMtYTZD3nnWenBVC8UaACLifiJFtZrio9zY35gfWaZtWw9ms1 giOAZKMcxCroIK+yvJm4YcdQWXEwcLBvrahsnNM9OT0YaegA8oxlrLt9BG0zVwh31PAO TiOnEuQ1b2gqzpN6raKEZLiUL5JrRQ/auuOg0znCrS8X43zeojcKIUw38gyVrCqoYmSe V8taWfwMwQ4R1dyBtKTDmOq/OOV/yNs1adNwNX4LD61CvMC8FHiP8qzdsLb2i9ikVRWT /UmiNZZzNa0WvwSyg+XxCTGxkkaay+CcmBnF6LOC+8Iy4eQbTLlcAcolC1+RAg/GEdZX FtNg== X-Gm-Message-State: ALoCoQm5lyQ6zZK4d0iPqCdFU9wMxfb7OW/ZWju59qL650gl0wkJtlaEf4ziY0+U6PwlBMWSlXWG X-Received: by 10.194.93.198 with SMTP id cw6mr2417622wjb.3.1442754088287; Sun, 20 Sep 2015 06:01:28 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.75.140 with SMTP id c12ls497882wiw.7.gmail; Sun, 20 Sep 2015 06:01:27 -0700 (PDT) X-Received: by 10.180.219.101 with SMTP id pn5mr7664028wic.89.1442754087052; Sun, 20 Sep 2015 06:01:27 -0700 (PDT) Original-Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com. [2a00:1450:400c:c05::230]) by mx.google.com with ESMTPS id hq5si24520500wjb.134.2015.09.20.06.01.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Sep 2015 06:01:27 -0700 (PDT) Received-SPF: pass (google.com: domain of andrewtomazos@gmail.com designates 2a00:1450:400c:c05::230 as permitted sender) client-ip=2a00:1450:400c:c05::230; Original-Received: by wicgb1 with SMTP id gb1so82647883wic.1 for ; Sun, 20 Sep 2015 06:01:27 -0700 (PDT) X-Received: by 10.194.103.103 with SMTP id fv7mr20502127wjb.152.1442754086814; Sun, 20 Sep 2015 06:01:26 -0700 (PDT) Original-Received: by 10.28.73.137 with HTTP; Sun, 20 Sep 2015 06:01:26 -0700 (PDT) In-Reply-To: <650f78b0-289e-4880-9c03-8615b25360ec@isocpp.org> X-Original-Sender: andrewtomazos@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of andrewtomazos@gmail.com designates 2a00:1450:400c:c05::230 as permitted sender) smtp.mailfrom=andrewtomazos@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=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:20521 Archived-At: --089e0103009cd7c95505202d5c1d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Sep 19, 2015 at 12:33 PM, Bengt Gustafsson < bengt.gustafsson@beamways.com> wrote: > - Do we really need to be able to specify the introducer character. Can't > % be fixed (with the usual %% escape possibility). > I considered that, but no matter what introducer you pick, there are always cases where the introducer is prevalent in the target string. This occurs in natural language, but is especially the case of code generation, where you are generating strings for later compilation in C++ or some other programming language. Having the introducer be defined at the start also makes it easier to read, as you are reminded what the special token is (just like the compiler is). Compare: F"The result of %x %% %y is not zero (it is %(x%y))." with F"$ The result of $x % $y is not zero (it is $[x%y])." Similar problematic examples can be found with any set predefined introducer or set predefined brackets. - Wouldn't it be more logical if this resulted in an expanded pack, i.e. a > number of comma separated parts. > format(std::cout, F"The number of %goods is %count"); > No, I think: std::cout F"% The number of %goods is %count"; is better. But I am considering changing the definition of an interpolated string to be a function call expression of return type std::interpolated_string. This would mean we would have to write: std::cout << F"% The number of %goods is %count"; (which some have requested anyway). But it also means we could also write: std::string s =3D F"% The number of %goods is %count"; or use it anywhere you can use a string normally. std::interpolated_string would contain: 1. a reference to the constant expression format string and positions of embedded expressions (which are known at compile time) 2. references to the values of the evaluated embedded expressions for the current execution. (calculated at run-time usually, but it should be constexpr-compatible) This means the operator<<(ostream&, interpolated_string) could be defined to stream out the substrings and subexpressions just like (and just as efficiently) as if you had written << for each. For the conversion from std::interpolated_string to std::string, it could use std::ostringstream internally or some more efficient method. So consumers of std::interpolated_strings could use operator<<(ostream&, std::interpolated_string), or use the conversion from std::interpolated_string to std::string implicitly (by just using std::string or std::string_view), or they could overload on std::interpolated_string. Users could also overload on std::interpolated_string to implement a translation mechanism, as they would have access to both the original source code text of the expressions as well as their evaluated values. std::interpolated_string would actually be a class template parametric on the types of the embedded expressions, but that's an implementation detail. > which calls a: > > template void format(ostream&, Ps&&...); > > Arbitrarily reusing << is a little bit to much of a hack for my taste. > Expanding as a pack to be picked up by a variadic template seems more lik= e > modern C++. The upcoming ... << ... type pack expansions > of C++17 would make the implementation of format a breeze. > > Even with a << expansion I would prefer not to introduce an prefix one at > the left, it seems more logical to write it out explicitly. > > - Translation is an important issue. > > There are utilities which scan the source code to find typically > _("string") literals which get translated. This does not seem to play wel= l > with > this suggestion. Translation is probably the most important reason for > placing the inserts after the string literal in printf and similar, and > this makes inline systems like shifting out on cout > much harder to translate, and this suggested system even worse, as the > parts of the literal can't be "addressed" at runtime so there is no chanc= e > of replacing the string with a translation. > > Translation is also a main driver behind prefering named inserts, as > different languages tend to want to reorder inserted words to get a > grammatically correct sentence. > > This said there are of course uses when translation is not an issue, but > I'm a bit worried that making untranslatable strings so much easier to us= e > than translatable strings will make American programmers (who are as lazy > as all programmers and create many of the most used softwares) convenient= ly > forget about the needs for translation. > > Of course it is still possible to make a preprocessor which actually > mangles the source code inserting the foreign string, but we want to move > away from those ideas towards being able to change language at runtime. > > > Den l=C3=B6rdag 19 september 2015 kl. 00:04:23 UTC+2 skrev Miro Knejp: > >> Nice, I wanted this so many times already. >> >> But there are a few points I find a bit strange. >> >> (1) I don't think operator<< is the right choice. With your proposal it >> means I cannot do the very basic thing that works in every language with >> string interpolation: >> std::string s =3D F"% Hello %i World!"; >> auto s =3D F"% Hello %i World!"; // What is auto? >> Any proposal that cannot get the above two lines to "just work" with >> standard types is simply not good enough in my oppinion. >> >> I believe to make this work properly one needs some other infrastructure >> to exist first. There has to be a way to pass the expression to be >> formatted to some function that knows how to format it? Last time I used >> string interpolation was in Scala, where the literal prefix is actually = the >> name of a function to call with the transformed string. I don't know >> whether we can ever introduce user defined string prefixes, but who know= s. >> However, I think for now, a more flexible way is to combine both prefix = and >> suffix. Let me try to explain with an example using your syntax where >> applicable: >> >> auto s =3D F"% Hello %i World: %{x =3D=3D 1 ? "a" : "b"}!"_my_string; >> >> This is translated to something like: >> auto&& __context =3D operator""_my_string(); >> __context("Hello "); >> __context(i); >> __context(" World: "); >> __context(x =3D=3D 1 ? "a" : "b"); // Note the correct handling of liter= als >> inside %{ } >> __context("!"); >> auto s =3D move(__context).get();d >> >> Whatever x this UDL returns must make the expression x(expr) well-formed >> for every expr that is an embedded expression of the string literal, or = an >> actual string literal. Unfortunately this requires that a string literal >> with *only* the introducing prefix is ill-formed, unless we make the >> exception that a lacking suffix uses a standard-library context that >> produces a std::string (whether this is a good idea is debatable, but it >> sure as hell would be friggin' convenient). Assuming no exceptions the >> get() method is invoked exactly once and therefore can use this knowledg= e >> to move the result out of the object. The move() helps to prefer an >> rvalue-qualified overload if one exists. >> >> The UDL is declared as usual but takes no parameters: >> >> MyStringBuilder operator""_my_string(); >> >> This suggests that the context cannot take constructor parameter, which >> may be a severe limitation. If constructor arguments are desirable then = it >> would certainly need a syntax that distinguishes this UDL from others (o= r >> find a solution other than UDLs). An interpolated string that is used fo= r a >> purpose other than being stored in some location (like performing output= ) >> it is more efficient to perform the output directly, which I guess is th= e >> motivation of using operator<<. A context that can take parameters could >> make this possible, for example using llvm::raw_ostream (a faster >> alternative to std::ostream): >> >> using namespace llvm; >> raw_ostream out; >> F"% Hello %i World: %{x =3D=3D 1 ? "a" : "b"}!"_raw_ostream{out}; >> >> Using a wrapper around raw_ostream that uses operator() instead of >> operator<< can directly insert into the stream with zero overhead compar= ed >> to a handwritten sequence of statements (same applies for std::ostream). >> What is weird about this syntax, though, is the placement of the "thing" >> that does the actual work at the end of the expression instead of the fr= ont >> as it were in a function call. Your approach with the receiving object a= t >> the front makes it at least *look* better. Maybe these can somehow be >> combined. >> >> Regardless of whether my approach here works or not, I think a solution >> that is not directly coupled to a certain operator (except the call >> operator) is less restricted and far more flexible. Function objects are >> way more common than insertion operators and maybe we can slow down the >> spreading abuse of operator<< . I know of some classes that could be an >> immediate drop-in and would "just work" with minimal adjustments. If the >> standard-provided string context uses ADL-based lookup to (for example) >> to_string(x), or to_string(context, x), you have a convenient customizat= ion >> point to support the default string interpolation. >> >> (2) Even if you stick to operator<< I find it *very* disturbing that >> there is no << between cout and the literal. >> >> cout F"% ..."; // Where's the operator? No call parens? Am I blind? Is >> the sky falling? >> cout << F"% ..."; // Ah, there it is! >> >> It also means that with your approach I couldn't pass the result of the >> interpolated literal as function parameter. >> >> foo(F"% ...") // ill-formed: foo(<< "...") >> >> (Which would be also ill-formed if the compiler can't find a matching >> operator<<, but that's a different issue.) >> >> It has to be as convenient and flexible as possible for the end-user. >> >> (3) I think it's very strange to have the escaping character be part of >> the string literal. To me it lacks a clear separation between the actual >> literal content and the introducer. Look at raw literals: >> R"delimiter(...)delimiter" where there is a clearly visible distinction >> between "content" and "non-content". Not sure how to do this properly, >> especially regarding the next point: >> >> (4) How does this combine with the other literal prefixes, like R? >> >> (5) There are actually two proposals in there: string interpolation and >> multiline literals. Those are completely orthogonal and you don't need t= he >> one to implement the other. You'd be better off making these two separat= e >> (independent) proposals. >> >> Am 18.09.2015 um 22:21 schrieb Andrew Tomazos: >> >> Please find attached a very very rough draft of a proposal entitled >> "Interpolated String Literals". >> >> Mainly after encouragement or discouragement, and any high-level thought= s >> you might have about it. >> >> -- >> >> --- >> 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-proposal...@isocpp.org. >> To post to this group, send email to std-pr...@isocpp.org. >> Visit this group at >> http://groups.google.com/a/isocpp.org/group/std-proposals/. >> >> >> -- > > --- > 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. > Visit this group at > http://groups.google.com/a/isocpp.org/group/std-proposals/. > --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --089e0103009cd7c95505202d5c1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Sep 19, 2015 at 12:33 PM, Bengt Gustafsson <bengt.gustafss= on@beamways.com> wrote:
=
- Do we really need to be able to specify the introducer character. Ca= n't % be fixed (with the usual %% escape possibility).

I considered that, but no matter what introduce= r you pick, there are always cases where the introducer is prevalent in the= target string.=C2=A0 This occurs in natural language, but is especially th= e case of code generation, where you are generating strings for later compi= lation in C++ or some other programming language.=C2=A0 Having the introduc= er be defined at the start also makes it easier to read, as you are reminde= d what the special token is (just like the compiler is).

Compare:

=C2=A0 =C2=A0F"The result of = %x %% %y is not zero (it is %(x%y))."

with

=C2=A0 =C2=A0F"$ The result of $x % $y is not z= ero (it is $[x%y])."

Similar problematic exam= ples can be found with any set predefined introducer or set predefined brac= kets.

- Wouldn't it be more logical if this resulted in an expanded pack, i.= e. a number of comma separated parts.

format(std::cout, F"The numbe= r of %goods is %count");

N= o, I think:

=C2=A0 std::cout F"% The number o= f %goods is %count";

is better.
But I am considering changing the definition of an interpolated= string to be a function call expression of return type std::interpolated_s= tring.

This would mean we would have to write:=

=C2=A0 std::cout << F"% The numbe= r of %goods is %count";

(which some hav= e requested anyway).

But it also means we could al= so write:

=C2=A0 std::string s =3D F"% The nu= mber of %goods is %count";

or use it anywhere= you can use a string normally.

std::interpolated_= string would contain:
1. a reference to the constant expressi= on format string and positions of embedded expressions (which are known at = compile time)
2. references to the values of the evaluated embedd= ed expressions for the current execution. (calculated at run-time usually, = but it should be constexpr-compatible)

This means = the operator<<(ostream&, interpolated_string) could be defined to= stream out the substrings and subexpressions just like (and just as effici= ently) as if you had written << for each.

Fo= r the conversion from std::interpolated_string to std::string, it could use= std::ostringstream internally or some more efficient method.
So consumers of std::interpolated_strings could use operator<= ;<(ostream&, std::interpolated_string), or use the conversion from s= td::interpolated_string to std::string implicitly (by just using std::strin= g or std::string_view), or they could overload on std::interpolated_string.=

Users could also overload on std::interpolated_st= ring to implement a translation mechanism, as they would have access to bot= h the original source code text of the expressions as well as their evaluat= ed values.

std::interpolated_string would actually= be a class template parametric on the types of the embedded expressions, b= ut that's an implementation detail.


which calls a:

<= div>template<typename... Ps> void format(ostream&, Ps&&..= ..);

Arbitrarily reusing << is a little bit t= o much of a hack for my taste. Expanding as a pack to be picked up by a var= iadic template seems more like modern C++. The upcoming ... << ... ty= pe pack expansions
of C++17 would make the implementation of form= at a breeze.

Even with a << expansion I woul= d prefer not to introduce an prefix one at the left, it seems more logical = to write it out explicitly.

- Translation is an im= portant issue.

There are utilities which scan the = source code to find typically _("string") literals which get tran= slated. This does not seem to play well with
this suggestion. Tra= nslation is probably the most important reason for placing the inserts afte= r the string literal in printf and similar, and this makes inline systems l= ike shifting out on cout
much harder to translate, and this sugge= sted system even worse, as the parts of the literal can't be "addr= essed" at runtime so there is no chance of replacing the string with a= translation.

Translation is also a main driver be= hind prefering named inserts, as different languages tend to want to reorde= r inserted words to get a grammatically correct sentence.

This said there are of course uses when translation is not an issue= , but I'm a bit worried that making untranslatable strings so much easi= er to use than translatable strings will make American programmers (who are= as lazy as all programmers and create many of the most used softwares) con= veniently forget about the needs for translation.

= Of course it is still possible to make a preprocessor which actually mangle= s the source code inserting the foreign string, but we want to move away fr= om those ideas towards being able to change language at runtime.
=


Den l=C3=B6rdag 19 september 2015 kl. 00:04:= 23 UTC+2 skrev Miro Knejp:
=20 =20 =20
Nice, I wanted this so many times already.

But there are a few points I find a bit strange.

(1) I don't think operator<< is the right choice. With your proposal it means I cannot do the very basic thing that works in every language with string interpolation:
std::string s =3D F"% Hello %i World!";
auto s =3D F"% Hello %i World!"; // What is auto?
Any proposal that cannot get the above two lines to "just work&quo= t; with standard types is simply not good enough in my oppinion.

I believe to make this work properly one needs some other infrastructure to exist first. There has to be a way to pass the expression to be formatted to some function that knows how to format it? Last time I used string interpolation was in Scala, where the literal prefix is actually the name of a function to call with the transformed string. I don't know whether we can ever introduce user defined string prefixes, but who knows. However, I think for now, a more flexible way is to combine both prefix and suffix. Let me try to explain with an example using your syntax where applicable:

auto s =3D F"% Hello %i World: %{x =3D=3D 1 ? "a" : &quo= t;b"}!"_my_string;

This is translated to something like:
auto&& __context =3D operator""_my_string();
__context("Hello ");
__context(i);
__context(" World: ");
__context(x =3D=3D 1 ? "a" : "b"); // Note the corr= ect handling of literals inside %{ }
__context("!");
auto s =3D move(__context).get();d

Whatever x this UDL returns must make the expression x(expr) well-formed for every expr that is an embedded expression of the string literal, or an actual string literal. Unfortunately this requires that a string literal with *only* the introducing prefix is ill-formed, unless we make the exception that a lacking suffix uses a standard-library context that produces a std::string (whether this is a good idea is debatable, but it sure as hell would be friggin' convenient). Assuming no exceptions the get() method is invoked exactly once and therefore can use this knowledge to move the result out of the object. The move() helps to prefer an rvalue-qualified overload if one exists.

The UDL is declared as usual but takes no parameters:

MyStringBuilder operator""_my_string();

This suggests that the context cannot take constructor parameter, which may be a severe limitation. If constructor arguments are desirable then it would certainly need a syntax that distinguishes this UDL from others (or find a solution other than UDLs). An interpolated string that is used for a purpose other than being stored in some location (like performing output) it is more efficient to perform the output directly, which I guess is the motivation of using operator<<. A context that can take parameters could make this possible, for example using llvm::raw_ostream (a faster alternative to std::ostream):

using namespace llvm;
raw_ostream out;
F"% Hello %i World: %{x =3D=3D 1 ? "a" : "b"}!= "_raw_ostream{out};

Using a wrapper around raw_ostream that uses operator() instead of operator<< can directly insert into the stream with zero overhead compared to a handwritten sequence of statements (same applies for std::ostream). What is weird about this syntax, though, is the placement of the "thing" that does the actual work at = the end of the expression instead of the front as it were in a function call. Your approach with the receiving object at the front makes it at least *look* better. Maybe these can somehow be combined.

Regardless of whether my approach here works or not, I think a solution that is not directly coupled to a certain operator (except the call operator) is less restricted and far more flexible. Function objects are way more common than insertion operators and maybe we can slow down the spreading abuse of operator<< . I know of some classes that could be an immediate drop-in and would "just work" with minimal adjustments. If the standard-provide= d string context uses ADL-based lookup to (for example) to_string(x), or to_string(context, x), you have a convenient customization point to support the default string interpolation.

(2) Even if you stick to operator<< I find it *very* disturbing that there is no << between cout and the literal.

cout F"% ..."; // Where's the operator? No call parens? A= m I blind? Is the sky falling?
cout << F"% ..."; // Ah, there it is!

It also means that with your approach I couldn't pass the result of the interpolated literal as function parameter.

foo(F"% ...") // ill-formed: foo(<< "...")
(Which would be also ill-formed if the compiler can't find a matching operator<<, but that's a different issue.)

It has to be as convenient and flexible as possible for the end-user.

(3) I think it's very strange to have the escaping character be par= t of the string literal. To me it lacks a clear separation between the actual literal content and the introducer. Look at raw literals: R"delimiter(...)delimiter" where there is a clearly visible distinction between "content" and "non-content". No= t sure how to do this properly, especially regarding the next point:

(4) How does this combine with the other literal prefixes, like R?

(5) There are actually two proposals in there: string interpolation and multiline literals. Those are completely orthogonal and you don't need the one to implement the other. You'd be better off making these two separate (independent) proposals.

Am 18.09.2015 um 22:21 schrieb Andrew Tomazos:
Please find attached a very very rough draft of a proposal entitled "Interpolated String Literals".

Mainly after encouragement or discouragement, and any high-level thoughts you might have about it.

--

---
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.<= br> To post to this group, send email to std-pr...@is= ocpp.org.
Visit this group at http://groups.goog= le.com/a/isocpp.org/group/std-proposals/.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/gro= up/std-proposals/.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--089e0103009cd7c95505202d5c1d-- .