220 36885 <305b7669-0744-473e-9715-807b7e8051b6@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: florian.csdt@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: String interpolation Date: Mon, 12 Feb 2018 08:15:33 -0800 (PST) Lines: 704 Approved: news@gmane.org Message-ID: <305b7669-0744-473e-9715-807b7e8051b6@isocpp.org> References: <356d5835-f1bf-4699-94f5-0b2d3d0b9c0e@isocpp.org> <25CCF885-86AD-4D51-8F5C-C46376D34DE0@gmail.com> <4890431.TR9UepuQra@tjmaciei-mobl1> <1cdb6300-7397-46d7-bce9-62e6e8dac40b@isocpp.org> <4bce681e-e729-4124-9322-69291fdb6678@isocpp.org> <8e456af5-09c3-461d-8562-30df127e93af@isocpp.org> <28e80709-5ebb-44d2-b26d-22cafd681330@isocpp.org> <52b86f0a-b3b9-455f-9d4d-0f6b15192c90@isocpp.org> <1e9a5468-6efa-48a2-87ce-6bdb6d5c4e83@isocpp.org> <750ecf62-9637-40f4-8585-e3be2780fb46@isocpp.org> <5b5435db-772e-4c38-8867-f6fbc66d7cec@isocpp.org> <5c51d89a-54b6-490b-87f2-09ed263d8322@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_9940_1758140889.1518452133069" X-Trace: blaine.gmane.org 1518452039 28783 195.159.176.226 (12 Feb 2018 16:13:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Feb 2018 16:13:59 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC26HM4V3MIRBJX3Q3KAKGQE6QIE74Y@isocpp.org Mon Feb 12 17:13:55 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1elGjR-0005f1-TO for gclcip-std-proposals@m.gmane.org; Mon, 12 Feb 2018 17:13:30 +0100 Original-Received: by mail-vk0-f70.google.com with SMTP id b195sf9140589vkf.8 for ; Mon, 12 Feb 2018 08:15:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=pK9Gy/CrEgOpnqRzOm5K+nwzTc7UfW3Dvr4VXlnfQ7U=; b=NoRmkoLMgBMd/gPsQE2d4sTnxCjZHCfw0Kerwv98Kklm+YqiW99TIhXFiUYIlfFDpH //4ufm6jadsHj6arVwZnkvEENrjDBB4Z3FAEY5uY930XfThtrkY54OdXWa+MD/kYenf1 O5D607Yx9SUyQw2ymga/S9zRLtMzqHRxiZ4gDuDliLkWRew83haWUsCiJq/EqrAsU8Mb /pk+Qqc7j5ECFxoqGRgkVSSphoRvt809jACJVdGltZM4mDW06v5ik/qG/6I+hnFZ1tIc u4fW+jlFlns+NxOA81bE9nOXCEzruMHs3NxtfwvOx1sU43syDtIdP/sxNDC2a8ItXyUh /arw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=pK9Gy/CrEgOpnqRzOm5K+nwzTc7UfW3Dvr4VXlnfQ7U=; b=U29HRAh3ySALH3UsXmV4gqqG65nw4bH5TFbX8x3CDtb4itvbr0/RJC8fefWPjm7Cbu 2+AKWfj3cUK0HEisB7qE4JTzDorLqvrOc9X7GfobLgyUdxfeTh98frYR0P7Gv6W95lHl IZzJsi902rhEnOjmSgIsXHBjF9AaCnw09Caw5rBkQ6jzQ1v1Z1dRYv6wHQwSNBv+H/2f dlbJPF3JvAPHhFFkC/L1ncyavswDj6QJwE1826WcZ6RF1Mx2JszTgE0jIGTlwuTV/1C4 OV4UV3eig4FhJ7M80zER/K1D3KDINp8go5ktEOtEUg5CZGmZASm5YkWvm7hrkYJM93Cj /L4A== 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: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=pK9Gy/CrEgOpnqRzOm5K+nwzTc7UfW3Dvr4VXlnfQ7U=; b=HrZE7li6mc89QntbUn742Xr/eyvdbJuZCyOUTFiGXyU+dh+fD9DlTTrDQQbr0f6xI6 g/T1vh6dgxHDVnHZBc/KG2gsEgTMT0J9rWA01NlhltoppLH5VymtGAz1DBLwHQzZQJzv AuIqeXKHhdmRcTBtnfl2U0DiwyWQE0m1jVdj3w1GN4BYMV7iMCxHSs7ZNfyBc2B30A0s zCvRSO6C/OBj47Bj0MImTmuFmC+gpD5F2Ohf/lksP5mDloFDUQuAC4Lcb35wf6Yk+rOg WWMd+sunCw55BXgGsRgEy0fO0urxHhIQpKLpEsHVscadwqZFJ9bMczZDKJQsz2cY455M I/SA== X-Gm-Message-State: APf1xPDbS8/EeUwYeY5pq3r0OhNMSreU1A0CdrPZbSBFYFnIBSfWtxf5 F1//bWqADEGTzO/ckFRG69b48w== X-Google-Smtp-Source: AH8x227jyeUYlf8zmibiDtx9eUOMb/Z6ZJp90Pl6noI6yHJYtFx2raK8pwkisKcMBB8H50I3DhzNSw== X-Received: by 10.31.166.17 with SMTP id p17mr3654429vke.104.1518452135408; Mon, 12 Feb 2018 08:15:35 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.135.84 with SMTP id j81ls1976494vkd.6.gmail; Mon, 12 Feb 2018 08:15:33 -0800 (PST) X-Received: by 10.31.178.206 with SMTP id b197mr1083140vkf.11.1518452133565; Mon, 12 Feb 2018 08:15:33 -0800 (PST) In-Reply-To: <5c51d89a-54b6-490b-87f2-09ed263d8322@isocpp.org> X-Original-Sender: florian.csdt@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:36885 Archived-At: ------=_Part_9940_1758140889.1518452133069 Content-Type: multipart/alternative; boundary="----=_Part_9941_2001226193.1518452133071" ------=_Part_9941_2001226193.1518452133071 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le lundi 12 f=C3=A9vrier 2018 16:45:41 UTC+1, Nicol Bolas a =C3=A9crit : > > On Monday, February 12, 2018 at 10:14:25 AM UTC-5, floria...@gmail.com=20 > wrote: >> >> Le lundi 12 f=C3=A9vrier 2018 15:56:12 UTC+1, Nicol Bolas a =C3=A9crit : >>> >>> On Monday, February 12, 2018 at 5:17:45 AM UTC-5, floria...@gmail.com= =20 >>> wrote: >>>> >>>> Let me suggest something close to Nicol's solution, but not quite. >>>> >>>> The F"" operator returns a special type that could be like a simple=20 >>>> tuple (let's name it std::string_processing for now). >>>> >>>> Then the user can use it directly into its own functions. >>>> >>>> >>>> auto column =3D "col"s; >>>> auto table =3D "tab"sv; >>>> auto req =3D sql(F"select {column} from {table};"); >>>> >>>> // would be equivalent to: >>>> auto req =3D sql(std::string_processing>>> const char[7]&, std::string_view&, const char[2]&>("select ", column, = "=20 >>>> from ", table, ";")); >>>> >>>> Now, if we want, we could also support UDL (but not mandatory) by=20 >>>> allowing to call UDL on the std::string_processing: >>>> >>>> auto column =3D "col"s; >>>> auto table =3D "tab"sv; >>>> auto req =3D F"select {column} from {table};"_sql; >>>> >>>> // would be equivalent to: >>>> auto req =3D operator ""_sql (std::string_processing>>> ::string&, const char[7]&, std::string_view&, const char[2]&>("select = " >>>> , column, " from ", table, ";")); >>>> >>>> Now let's have some examples of it could be: >>>> >>>> Simple string concatenation would be simple >>>> auto concatenated =3D F"{str1}{str2}{str3}"s; >>>> // converted into an efficient concatenation of the 3 strings >>>> >>>> We could print it into an iostream if we want (but would be here only= =20 >>>> for convenience on legacy code) >>>> std::cout << F"{str1}{str2}\n"; >>>> // equivalent to: >>>> std::cout << str1 << str2 << "\n"; >>>> >>>> It could be implicitly convertible to a std::string (only if variables= =20 >>>> are implicitly convertible to std::string) >>>> std::string concatenated =3D F"{str1}{str2}"; >>>> >>>> (No example with FMT as I don't know how it works, but I don't see any= =20 >>>> reason for it not to be compatible with FMT.) >>>> >>>> And this would be constexpr-able. >>>> >>>> Now, formatting would require a bit more elaborated type that could=20 >>>> store formatting information. >>>> But in the end, only the user will know what to do with it. >>>> However, I would prefer *not* to embed formatting in such a type, just= =20 >>>> to keep it simple. And use a library based solution when I really need= =20 >>>> formatting. >>>> >>>> It has all the advantages of Nicol's solution, while being more=20 >>>> versatile. >>>> >>> >>> I fail to see the versatility here, and it does not have all of the=20 >>> advantages of my method. >>> >>> Remember, in my version, UDLs only apply to the string fragments. In=20 >>> your version, you *cannot* apply UDLs to string fragments; the string= =20 >>> fragments will be packed into your `string_processing` type as views or= =20 >>> some such. >>> >>> Then there's ease of use. Let's see how to implement stream-based strin= g=20 >>> concatenation with my method: >>> >>> template >>> auto concat(Args ...&&args) >>> { >>> std::ostringstream stream; >>> stream << ... << std::forward(args); >>> return std::move(stream).get(); >>> } >>> >>> Simple and obvious, a standard bit of C++17 variadic template=20 >>> programming. >>> >>> Now, how would you go about doing that with `string_processing`? That= =20 >>> would require template metaprogramming: >>> >>> template >>> void concat_items(std::ostringstream &stream, std::string_processing< >>> Args...> &&proc, std::index_sequence) >>> { >>> stream << ... << get(proc)); >>> } >>> >>> template >>> auto concat(std::string_processing &&proc) >>> { >>> std::ostringstream stream; >>> concat_items(stream, std::move(proc), std::make_index_sequence>> ...(Args)>{}); >>> return std::move(stream).get(); >>> } >>> >>> This isn't the hardest code to write in the world, but it is much more= =20 >>> complex than the previous one. Also, perfect forwarding doesn't really = work=20 >>> here. >>> >>> Also, the variadic version of `concat` can be used with stuff that isn'= t=20 >>> the result of string interpolation. Or with multiple interpolated strin= gs.=20 >>> And so forth. Whereas your `string_processing` type is a magic type tha= t=20 >>> only the compiler can create. And we already have a type that does what= =20 >>> `string_processing` does; it's called `tuple`. >>> >>> The *only advantage* your method has over mine is that it allows UDLs= =20 >>> to define the aggregation operation. Why is this so important to so man= y=20 >>> people? >>> >>> >> >> Well, my solution is more versatile in the following sense: the result i= s=20 >> a plain object that can be stored in a variable, returned from a functio= n. >> > > tuple(F"interpolated {string}") > > Oh look, "a plain object that can be stored in a variable, returned from = a=20 > function". It required a whole 7 characters more. > > "Versatility" typically refers to the ability to do more things with=20 > something. My way can be put into an object, but your way cannot be put= =20 > into a function's parameters as separate values nearly as easily. Mine=20 > seems more versatile. > > You could envision functions to transform std::string_processing into=20 >> another std::string_processing easily. >> >> Moreover, I know that some proposals try to enable creating a parameter= =20 >> pack from a tuple (like an operator... ). >> > > And sadly, none of them have advanced or even received additional revised= =20 > proposals. My way works just fine with C++ as it is. > > And even if we had that, most use-cases you don't need to pass the values= =20 > around as a collective object. And if you did, you can make one trivially= ,=20 > as above. > > And again, it still doesn't deal with the fact that you lose perfect=20 > forwarding. > =20 I understand your point about creating a tuple from a parameter pack to be= =20 able to do what is natural with my proposal. Fair enough. However, I don't see how we lose perfect forwarding. I mean, if the=20 variable is a lvalue, it is stored as an lvalue reference, and if it is a= =20 rvalue, it is stored as an rvalue reference. This would be the exact same rules as for std::forward_as_tuple. > With that in mind, the implementation of your concat function with my=20 >> approach would be exactly the same as with your approach (with a call to= =20 >> "operator..." of std::string_processing ). >> >> And then, with only c++17 metaprogramming capabilities, you could also= =20 >> use std::apply. >> > > You cannot `apply` things to operators. Not without creating a lambda=20 > function that gets called with it. > =20 Why not? You can get the address of an operator, and this is a callable=20 object. > The fact is, it's a *lot* easier in C++ as it currently stands to go from= =20 > parameter pack of values to an object than it is to go from an object to = a=20 > parameter pack of values. I wish that were not the case, but so long as i= t=20 > is the case, parameter packs will remain the easier-to-use option. > =20 You have a point.=20 > UDL the aggregate is not important to me, but it was easy to include and= =20 >> allows neat syntax (in my opinion). >> > > But it makes it impossible to apply a UDL to the string fragments. And=20 > that's important if you do want to use template metaprogramming on string= =20 > literals. > I'm not sure to see the use case here. When you use UDL, you want the whole= =20 literal to be what you say it would be. auto s =3D "something"s; // s is a string auto sv =3D "some other"sv; // s is a string view We are not interested in what is happening in the middle. I don't why it=20 should be different with string interpolation (or whatever the name is). And with my proposal, you can always apply a function to every single=20 element, and this function can be a UDL if you really want. To sum up, F"something" returning a parameter pack is probably the way to= =20 go because of the current C++, but would not bring that much with a proper= =20 C++. And then, I think UDL should apply to the whole stuff and not its part. Assuming operator F"" returns a parameter pack: auto s =3D F"{args}..."s; // equivalent to: auto s =3D operator ""s(args...); // If you want to apply a UDL to part of it: operator ""s(F"{args}...")... // would be equiavlent to: operator ""s(args)... --=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/305b7669-0744-473e-9715-807b7e8051b6%40isocpp.or= g. ------=_Part_9941_2001226193.1518452133071 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le lundi 12 f=C3=A9vrier 2018 16:45:41 UTC+1, Nico= l Bolas a =C3=A9crit=C2=A0:
On Monday, February 12, 2018 at 10:14:25 AM UTC-5, floria.= ...@gmail.com wrote:
Le lundi 12 f=C3=A9vrier 2018 15:56:12 UTC+1, Nicol Bolas a =C3=A9crit= =C2=A0:
On Monday, = February 12, 2018 at 5:17:45 AM UTC-5, floria...@gmail.com wrote:
Let me suggest someth= ing close to Nicol's solution, but not quite.

The F"" = operator returns a special type that could be like a simple tuple (let'= s name it std::string_processing for now).

Then the user can use it = directly into its own functions.


auto column =3D "col"s;
auto table =3D "tab"<= /span>sv;
auto req =3D sql(F"selec= t {column} from {table};");

// would= be equivalent to:
auto req =3D sql(std::string_processing<cons= t char<= /span>[8]&, std::string<= /span>&, <= /span>const char[7]&, std::string_view= &, = const c= har[2]&>("select ", column, " from ", table, ";"));<= /span>

Now, if = we want, we could also support UDL (but not mandatory) by allowing to call = UDL on the std::string_processing:

auto column =3D "col"s;
auto table =3D "tab"sv;
auto<= span style=3D"color:#000"> req =3D= F"select= {column} from {table};"_sql<= span style=3D"color:#660">;

// would be equivalent to:
auto req =3D operator ""_sql (std::string_processing&l= t;const= char[<= /span>8]&,= std::<= /span>string&a= mp;, co= nst cha= r[7]&, std= ::strin= g_view&, const char[2]&a= mp;>("select ", column, " from ", table, ";"= ;));

Now let's have some examples of it could= be:

Simple string concatenation would be simple
auto concatenated = =3D F&q= uot;{str1}{str2}{str3}"s;
// converted into an efficient concatenation of the 3 s= trings

W= e could print it into an iostream if we want (but would be here only for co= nvenience on legacy code)
=
std::cout <&l= t; F&qu= ot;{str1}{str2}\n";
// equivalent to:
std::<= /span>cout <= ;< str1 << str2 << "\n";

It could be implicit= ly convertible to a std::string (only if variables are implicitly convertib= le to std::string)
std::string concatenate= d =3D F= "{str1}{str2}";

(No example with FMT as I don't know how it works, but I don= 't see any reason for it not to be compatible with FMT.)

And thi= s would be constexpr-able.

Now, formatting would require a bit more = elaborated type that could store formatting information.
But in the end,= only the user will know what to do with it.
However, I would prefer = not to embed formatting in such a type, just to keep it simple. And use= a library based solution when I really need formatting.

It has all = the advantages of Nicol's solution, while being more versatile.

I fail to see the versatility here, and it does not= have all of the advantages of my method.

Remember, in my version, U= DLs only apply to the string fragments. In your version, you cannot = apply UDLs to string fragments; the string fragments will be packed into yo= ur `string_processing` type as views or some such.

Then there's = ease of use. Let's see how to implement stream-based string concatenati= on with my method:

template<= typename ...Ar= gs><= br>auto= concat(Args .= ...&&args)
{
=C2=A0 std::ostringstream stream;
=C2= =A0 stream << ... << std::forward<Args>(args);
=C2=A0 return= std::<= span style=3D"color:#000">move(stream).get();
}

Simple and obvious, a standard bit of C++17 variadic temp= late programming.

Now, how would you go about doing that with `strin= g_processing`? That would require template metaprogramming:

templ= ate<= typename ...Args, size_t ...Ints>
void concat_items(std::ostringstream = &stream, std::string_pro= cessing<Args...> &&proc, std::index_sequence<= Ints...>)
{
=C2=A0 stream << ... << get<Ints>(proc));
}

template<typename ...Args>
auto concat(std::string_processing<= Args...> &&proc)
{
=C2=A0 std::ostringstream stream;
=C2= =A0 concat_items(stream, std::move(proc), std::make_index_sequence<size...(= Args)>{});<= /span>
=C2=A0 return std::move(stream).get();
}

This isn't the hardest code to write = in the world, but it is much more complex than the previous one. Also, perf= ect forwarding doesn't really work here.

Also, the variadic vers= ion of `concat` can be used with stuff that isn't the result of string = interpolation. Or with multiple interpolated strings. And so forth. Whereas= your `string_processing` type is a magic type that only the compiler can c= reate. And we already have a type that does what `string_processing` does; = it's called `tuple`.

The only advantage your method has o= ver mine is that it allows UDLs to define the aggregation operation. Why is= this so important to so many people?

=

Well, my solution is more versatile in the following sen= se: the=20 result is a plain object that can be stored in a variable, returned from a function.

tuple(F"interpolated {string}"= )

Oh look, "a plain object that can be st= ored in a variable, returned from a function". It required a whole 7 characters more.

"Vers= atility" typically refers to the ability to do more things with someth= ing. My way can be put into an object, but your way cannot be put into a fu= nction's parameters as separate values nearly as easily. Mine seems mor= e versatile.

You could envision functions to transform std::string_process= ing into another std::string_processing easily.

Mo= reover, I know that some proposals try to enable creating a parameter pack = from a tuple (like an operator... ).

And s= adly, none of them have advanced or even received additional revised propos= als. My way works just fine with C++ as it is.

And even if we had th= at, most use-cases you don't need to pass the values around as a collec= tive object. And if you did, you can make one trivially, as above.

A= nd again, it still doesn't deal with the fact that you lose perfect for= warding.
=C2=A0
I understand you= r point about creating a tuple from a parameter pack to be able to do what = is natural with my proposal. Fair enough.

However,= I don't see how we lose perfect forwarding. I mean, if the variable is= a lvalue, it is stored as an lvalue reference, and if it is a rvalue, it i= s stored as an rvalue reference.
This would be the exact same rul= es as for std::forward_as_tuple.


With that in mind, the impleme= ntation of your concat function with my approach would be exactly the same = as with your approach (with a call to "operator..." of std::strin= g_processing ).

And then, with only c++17 metaprog= ramming capabilities, you could also use std::apply.

You cannot `apply` things to operators. Not without creating= a lambda function that gets called with it.
=C2=A0
Why not? You can get the address of an operator, and th= is is a callable object.


The fact is, it's a lot= easier in C++ as it currently stands to go from parameter pack of values t= o an object than it is to go from an object to a parameter pack of values. = I wish that were not the case, but so long as it is the case, parameter pac= ks will remain the easier-to-use option.
= =C2=A0
You have a point.


UDL the a= ggregate is not important to me, but it was easy to include and allows neat= syntax (in my opinion).

But it makes it imp= ossible to apply a UDL to the string fragments. And that's important if= you do want to use template metaprogramming on string literals.
<= /div>

I'm not sure to see the use case = here. When you use UDL, you want the whole literal to be what you say it wo= uld be.
auto s =3D= "something&quo= t;s= ; // s is a string
auto sv =3D "some other"sv; // s is a string view
We are not interested in what is = happening in the middle. I don't why it should be different with string= interpolation (or whatever the name is).

And = with my proposal, you can always apply a function to every single element, = and this function can be a UDL if you really want.


To sum up, F"something" returning a parameter pac= k is probably the way to go because of the current C++, but would not bring= that much with a proper C++.
And then, I think UDL should apply = to the whole stuff and not its part.

Assuming oper= ator F"" returns a parameter pack:
auto s =3D F"{args}..."s;
// equivalent to:
auto s = =3D operator<= span style=3D"color: #000;" class=3D"styled-by-prettify"> ""s(args...);

// If you want to apply a UDL to part of it:
operator ""s(F"{args}...")...
// would be equiavlent to:
operator ""s(a= rgs)...

--
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/305b7669-0744-473e-9715-807b7e8051b6= %40isocpp.org.
------=_Part_9941_2001226193.1518452133071-- ------=_Part_9940_1758140889.1518452133069-- .