220 36861 <8e456af5-09c3-461d-8562-30df127e93af@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: inkwizytoryankes@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: String interpolation Date: Sat, 10 Feb 2018 10:39:45 -0800 (PST) Lines: 410 Approved: news@gmane.org Message-ID: <8e456af5-09c3-461d-8562-30df127e93af@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6744_1031796837.1518287985319" X-Trace: blaine.gmane.org 1518287884 25217 195.159.176.226 (10 Feb 2018 18:38:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 10 Feb 2018 18:38:04 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDDLTAGNTIBBB4XY7TJQKGQEF4KGISI@isocpp.org Sat Feb 10 19:38:00 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f199.google.com ([209.85.217.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eka1u-000575-I5 for gclcip-std-proposals@m.gmane.org; Sat, 10 Feb 2018 19:37:42 +0100 Original-Received: by mail-ua0-f199.google.com with SMTP id z11sf7257657uaz.0 for ; Sat, 10 Feb 2018 10:39:48 -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=5WjwGrjUf5nDAz6FLTxJsjo3SsuCxONvnE7M5xBN4/U=; b=GxVZDu0ZuZPtYHgLZxRX5db9g5U3OjUv0X4K8SwKBC7+vkl1h7jeFch3xBtaSkPzZ5 3BZv8TqPLI6TyrcOgrB6BGFq+RRwCNH+vG7W6FeatKyHKFPSXmcHQBgfYjD5mAXS1Df6 Xmnh07WrDV0eU4s9QN9zhiMA1s4jytAF+s4b2/dxWlBC2WQMREcMctN1mLyQdS7vmkjS 44mqHAWZV6cXjo0nh4jCJzN0W7qCYmpGDzNop8sKxmHC/dN9lK8gDtSx+9nXvfVVYQZT VGffGzHasNsLRN6F9iBQyQjOKQq7MeMlGpKH8yX1tO6SDo6bkbk+y2YyecXSNL4hZ4mm d/ig== 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=5WjwGrjUf5nDAz6FLTxJsjo3SsuCxONvnE7M5xBN4/U=; b=PG3N8RDDwOSvFeC4mZ8sCGDRkzBhSKNvY3wZULEdfo095iiBZM0CoKKqXNSISi0Fqo YGU3Y3wTBuA5yD7eZfCPP/4YxAfL88pEPBf1D8SizeUoolhtJmwYnWmOcwwJHKI4+N/7 AOSgu0lC9NjSFI75z7bccGZznuOfL2gHzoncFWbCtyWnXr3HiDg6b4DWV2EmNeQ+nz53 jlE4+OpOdz6twD1VD7JPiqwDY+WBfDf4LiwJzF6Y3u4w2AthLAKlmJ8Cvk311/J/9fi6 YhGED4XZF7n+13GkkYR3v4zDdkbyiLPhmq94/UGtPuQU7emm7rJF8g6kkJjQ8LmA4XN9 JWBQ== 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=5WjwGrjUf5nDAz6FLTxJsjo3SsuCxONvnE7M5xBN4/U=; b=KJhbElPR2T/EfgRLg/vFcNBCUOojNrcugT6okhHOYLbzD5syUz28RbGUD79ebdPzu1 /TJUo8M8EFHiF1+Ow0q6n9LY20oSenmUEsQN+npNn04bQ6oMyIoeZ8/jkNPmG+3Tiiba XcgnkwEdPtIOPoUkncfgsTl0LYSWwdkmNVV8Y3wSdb03wE8QwkJfFx+OkKEPU3zPhwxX DmUO4BhSyWrRpiTwJ3jtfV2tYv2VhHf5tAIdKnqUiEu9haHYZwgK+GFUpoZnmmQQU9rS Zl2HlrYCckSG2nCXGoiWGrNB7AARQQSwlIR8TQlOpYYb+ciKBo9dzFp6BiKPoaA5u0nl 6URg== X-Gm-Message-State: APf1xPDCMmUtmdY5ZWpQMEVBLn6g1hfHsx6Rx3jBHpR3yXDwpIe/dItI NQGuQW0Yk47tfe48a7q8IoE93g== X-Google-Smtp-Source: AH8x225vm9/XTymUUl3IVqxqMnRzN/709QRrYLKq77N/lcMEkQn3I05SjmndRKpnLvpQqz7/tTS8Tg== X-Received: by 10.159.36.17 with SMTP id 17mr3847250uaq.119.1518287987668; Sat, 10 Feb 2018 10:39:47 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.191.147 with SMTP id p141ls5306370vkf.19.gmail; Sat, 10 Feb 2018 10:39:46 -0800 (PST) X-Received: by 10.31.136.139 with SMTP id k133mr573291vkd.8.1518287985849; Sat, 10 Feb 2018 10:39:45 -0800 (PST) In-Reply-To: X-Original-Sender: inkwizytoryankes@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:36861 Archived-At: ------=_Part_6744_1031796837.1518287985319 Content-Type: multipart/alternative; boundary="----=_Part_6745_2004159494.1518287985320" ------=_Part_6745_2004159494.1518287985320 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Saturday, February 10, 2018 at 6:30:15 AM UTC+1, Nicol Bolas wrote: > > > > On Friday, February 9, 2018 at 5:12:26 PM UTC-5, Marcin Jaczewski wrote: >> >> >> >> On Friday, February 9, 2018 at 10:13:10 PM UTC+1, Jake Arkinstall wrote: >>> >>> >>> >>> On 9 Feb 2018 20:51, wrote: >>> >>> >>> Minimal version than could be added to C++ is new string prefix `F`=20 >>> (because we have `R`, `u`, `u8` and `U` already, and `$` is outside of= =20 >>> source characters) that enable mixing code with string literals. >>> As Marcel Kr=C3=BCger wrote, language could transform this string liter= al to: >>> F"testA{a}test{{B}}"_x; =3D> operator""_x("testA"_x, a, "test{B}"_x); /= /using=20 >>> same postfix to parse sub-literals >>> FR"aa(x{b}y)aa"_x; =3D> operator""_x(R"aa(x)aa"_x, b, R"aa(y)aa"_x); //= it=20 >>> have precedence over `R` prefix >>> >>> >>> >>> Rest will be implemented by library, this mean `F"a {5} b"` will not=20 >>> compile because there is no matching operator. stl could add this opera= tor=20 >>> for `s` postfix, that will use `std::to_string` for conversing all=20 >>> arguments: >>> template >>> std::string operator""s(Parts&&... p) { return std::to_string(std:: >>> forward(p)) + ...; } >>> >>> int main() >>> { >>> auto x =3D F"Test {{a}} =3D {10+5}"s; //x =3D=3D "Test {a} =3D 15"s >>> } >>> No iosteam, and even more it could if someone relay desire to have=20 >>> localizations: >>> >>> F"Test {356*10}"_loc("Prod {0} OK!", "fr") =3D=3D "Prod 3.560,00 OK!"; >>> >>> Only drawback is some template bloat but this is probably acceptable=20 >>> cost. >>> >>> >>> This is exactly the kind of thing I'm aiming for, although I dont=20 >>> believe string conversion and concatenation to be the final solution -= =20 >>> unless my recall of benchmarks is out of date, streams are faster than= =20 >>> string concatenation. >>> >>> This being said, similar ideas can be applied to utilise the fmt=20 >>> library, for example. >>> >> =20 >> This is irrelevant, how it will be implemented is QoI, It could be done= =20 >> using `snprintf`, or even not implemented at all, only prefix `F`and its= =20 >> transformation is important. >> >> More I think about this more it look as great addition to language: >> std::string a; >> int b =3D 0; >> int c =3D 42; >> db.run(F"select name as {a}, age as {b} from table where id =3D {c}"_sql= ); >> >> > If how this is implemented is a mere implementation detail, how would you= =20 > make it use bound parameters or otherwise sanitize string inputs? Have we= =20 > learned nothing from Little Bobby Tables ? > > Indeed, this seems like a justification to *not* provide this feature. > =20 But it can easy check it, `_sql` is not string, if you pass string then it= =20 will be escaped before it is appended to finals string that is send to=20 database. And how it will be exactly implemented? Like this: db.run(operator""_sql("select name as "_sql, a, ", age as "_sql, b, "from= =20 table where id =3D "_sql, c, ""_sql)); This will call: sql_command operator""_sql(sql_command, std::string& a, sql_command, int& b= ,=20 sql_command, int& c, sql_command); We have all needed information how to handle each parameter. We can take address of `a`, `b`, and `c`. We can merge parts of sql and=20 merge in one querry. From that we can deduce usage and if type is string we add quotes and=20 escapes value (if we need pass some sql part then we use `" and state =3D 1= =20 "_sql` that return `sql_command` not `std::string`). It could too simply forward to some current implementation like: auto sql =3D sql_command("select name as PARAM_0, age as PARAM_1 from table= =20 where id =3D $0").bind(0, c).execute(db); a =3D sql.get("PARAM_0"); b =3D sql.get("PARAM_1"); Some of this transformation can be done at compile time (like constexpr=20 regexp). Because we can take reference to object then we can do two-way=20 communication. --=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/8e456af5-09c3-461d-8562-30df127e93af%40isocpp.or= g. ------=_Part_6745_2004159494.1518287985320 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Saturday, February 10, 2018 at 6:30:15 AM UTC+1= , Nicol Bolas wrote:


On Friday, February 9, 2018 at 5:12:26 PM UTC-5, Marcin Ja= czewski wrote:

=
On Friday, February 9, 2018 at 10:13:10 PM UTC+1, Jake Arkinstall wrote= :

On 9 Feb 2018 20:51, <= inkwizyt...@gmail.com> wrote:

Minimal version than could be added to C++ = is new string prefix `F` (because we have `R`, `u`, `u8` and `U` already, a= nd `$` is outside of source characters) that enable mixing code with string= literals.
As Marcel Kr=C3=BCger wrote, language could transform this st= ring literal to:
F"testA{a}tes= t{{B}}"_x; =3D> operator""_x("testA"_x, a, "test{B}"_x); <= span style=3D"color:#800">//using same postfix to parse sub-literals=
FR"aa= (x{b}y)aa"_x; =3D> operator""_x(R"aa(x)aa"_x, b, R"aa(y)aa"= ;_x); //it hav= e precedence over `R` prefix



Rest will= be implemented by library, this mean `F"a {5} b"` will not compi= le because there is no matching operator. stl could add this operator for `= s` postfix, that will use `std::to_string` for conversing all arguments:
template<typename... Parts>
std::string operator""s(Parts&&... p) = { return std::to_string(std<= span style=3D"color:#660">::forward<Part= s>(p= )) + ...; }

int main<= span style=3D"color:#660">()
{
=C2=A0 =C2= =A0 auto x =3D= F"Test {{a}} =3D {10+5}"s; //x =3D=3D "= Test {a} =3D 15"s
}
No iosteam, and even more it could if someone relay desire t= o have localizations:

=
F"Te= st {356*10}"_loc("Prod {0} OK!"= , "fr") =3D= =3D &qu= ot;Prod 3.560,00 OK!";

Only drawback is some= template bloat but this is probably acceptable cost.

T= his is exactly the kind of thing I'm aiming for, although I dont believ= e string conversion and concatenation to be the final solution - unless my = recall of benchmarks is out of date, streams are faster than string concate= nation.

This being said,= similar ideas can be applied to utilise the fmt library, for example.
=C2=A0
This is irrelevant, how it will be imple= mented is QoI, It could be done using `snprintf`, or even not implemented a= t all, only prefix `F`and its transformation is important.

More I th= ink about this more it look as great addition to language:
std= ::string a;
int b =3D 0;
int c =3D 42;
db.run(F"select name as {a}, age as {= b} from table where id =3D {c}"_sql<= /span>);

If how this i= s implemented is a mere implementation detail, how would you make it use bo= und parameters or otherwise sanitize string inputs? Have we learned nothing= from Little Bobb= y Tables?

Indeed, this seems like a justification to not = provide this feature.
=C2=A0

But it= can easy check it, `_sql` is not string, if you pass string then it will b= e escaped before it is appended to finals string that is send to database.<= br>And how it will be exactly implemented? Like this:
db.run(operator""_sql("select name as "_sql, a, ", age as "_sql<= span style=3D"color: #660;" class=3D"styled-by-prettify">, b, "from table where id =3D "_sql, c, ""_sql));

This will call:
sql_command operator""_sql(sql_command, std::string& a,= sql_comma= nd,= int& b, sql_command, int&= amp; c, sql_command);

We have all needed information how to handle each parameter.
= We can take address of `a`, `b`, and `c`. We can merge parts of sql and mer= ge in one querry.
From that we can deduce usage and if type is string we= add quotes and escapes value (if we need pass some sql part then we use `&= quot; and state =3D 1 "_sql` that return `sql_command` not `std::strin= g`).
It could too simply forward to some current implementation like:
auto sql <= span style=3D"color: #660;" class=3D"styled-by-prettify">=3D sql_command("select name as PARAM_0, ag= e as PARAM_1 from table where id =3D $0").bind(0, c).execute(db);
a =3D sql.g= et<std::string>("PARAM_0");
b =3D sql.get<int>(= "PARAM_1");

Some of this transformation can be= done at compile time (like constexpr regexp).

Because we can take r= eference to object then we can do two-way communication.



--
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/8e456af5-09c3-461d-8562-30df127e93af= %40isocpp.org.
------=_Part_6745_2004159494.1518287985320-- ------=_Part_6744_1031796837.1518287985319-- .