220 36910 article Path: news.gmane.org!.POSTED!not-for-mail From: Todd Fleming Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: String interpolation Date: Tue, 13 Feb 2018 17:03:16 -0800 (PST) Lines: 764 Approved: news@gmane.org Message-ID: 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> <305b7669-0744-473e-9715-807b7e8051b6@isocpp.org> <0ceb2063-d7b6-4cb8-8c5c-c63aceb5b549@isocpp.org> <41b87b07-1a91-4bca-ba00-5734c09dbe77@isocpp.org> <1a7f714d-4a91-4a95-8da4-0c688d18c4c4@isocpp.org> <5f8efcc0-f4e9-4518-abe5-5fffeab55083@isocpp.org> <0e0876bb-7a44-45ff-ab9b-6443e78ea59c@isocpp.org> <3468ee0c-a44a-437a-a835-0156c623df2e@isocpp.org> <589a55c8-d886-4bb1-b991-96c5e9fe910a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_12615_215957504.1518570196677" X-Trace: blaine.gmane.org 1518570090 1226 195.159.176.226 (14 Feb 2018 01:01:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 14 Feb 2018 01:01:30 +0000 (UTC) Cc: florian.csdt@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDN5JUVZSIFBBVUVR3KAKGQEWGTK5FQ@isocpp.org Wed Feb 14 02:01:25 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ellRi-0007mP-CD for gclcip-std-proposals@m.gmane.org; Wed, 14 Feb 2018 02:01:14 +0100 Original-Received: by mail-ua0-f197.google.com with SMTP id c40sf9311711uae.18 for ; Tue, 13 Feb 2018 17:03:20 -0800 (PST) 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:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=9SdzGW+Du9hvKV6S0PIMHR/cgzCot5hnoTWGWD3CPyA=; b=FC8QXtZuJxQvUZi5BbCAdH7pIZM/8ZcOsFg7vwQc+azzK4pLPQOgi0VQ6mjnJsV1Kb m6CnGLO/96Mj0xMuxg9A4r+shwmm1aFs8Q5ZZsHdHmnU8b8Sm1/TzM3+ajQ65Hq3VQ6k c2Fz7r93QdVvmOYEdvNkK48Dhbwi243iOr94A4QmmPm/OLmcZCUV+9LjGkEHS2QEujZQ l8JdL55e0Hgqhlz8hV4W9uoB0XvEj+hsM1poDBrMhmwo07iPa1266CWTfgbA9OPjFEZf wF8WAItonhGgfc4bnw+UawXtdINXWSNiM9oHwPz4wDB7ZZoeM+UK7Odl/47AfuIiHnoW id3w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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=9SdzGW+Du9hvKV6S0PIMHR/cgzCot5hnoTWGWD3CPyA=; b=bydktOEtKYu052F9ZFPVAhlEr27Nsf/N5cc4boiQ/qjs7kTNxHjzPiI4ddsDFrJ3IQ wAZvHFo4K0KTZxcNDfUxXKdyK/1SD5Oh+I0/a5GT3drWFuqS0HL6R9l9YMdUnq9Ag+jC OrDStsodOxA7z06E6KE+fxV0Qge9VKfWe5Pq0mSJvzKJjLfpMSdYQsr2tkqD03utSb3E kDs/Y8b0EUD5484Rg/y1lp3mvXTwbKiSQ5uHADXjSwzmGEK8cE+lSkpRe4ktsFbJTPGt ZZLiGTiOuv+qfkTbSe4CT1DXttxsr4MrF6wHlDG7ESfjpyY+Q8RD1LGmPcz0GXEl2Lzx tzng== 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=9SdzGW+Du9hvKV6S0PIMHR/cgzCot5hnoTWGWD3CPyA=; b=hw1JDNhQQeln7OeoqlbOkl4RlbSoIcpFdlPvn1pHnZFKDDYOph5p/kIW6y1j7K2kmI xddkk09r11kpovkQyVbVjPCjJgUyBWTX3g4Ku4vcU9wX+Kvglx2SOd8IlfQ9lbDhg901 hX1vv0AHFzd+/7dil7YgQMvCgVYDwVq9yFZlsUcR8U8Xlbdx9gkjbBA4+mrK5ICNLrhP 47Fa2BHjCyf30BQ0yZzBjU27nP/rCWKt/JaNiyotzp2lzAUr3tWFBBxE+imbFE+NNvI9 dVuMTI7dIRR7o5DsW9BXGEOit0PaO3ZEi/lr1AmFnWdO1D8EBryTBW685Zj4Nwjmkm8/ 2bdQ== X-Gm-Message-State: APf1xPCtRCUVpzt592Ta3WgNjIIkw2ApOlB2GXyfkXjzg1098qZYb/00 tEwCjtKrusZUwruYh2OXZ6Ss5g== X-Google-Smtp-Source: AH8x227WslBGkO8Tv1iA0Ik4qiuGRRIC64HgDX7erHmMxAyyZEusN5+O218hGD+flxtA+Mx/qjtzXg== X-Received: by 10.176.26.27 with SMTP id a27mr1552770uai.35.1518570199719; Tue, 13 Feb 2018 17:03:19 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.16.66 with SMTP id g63ls2285321vki.4.gmail; Tue, 13 Feb 2018 17:03:18 -0800 (PST) X-Received: by 10.31.178.206 with SMTP id b197mr269366vkf.11.1518570197539; Tue, 13 Feb 2018 17:03:17 -0800 (PST) In-Reply-To: <589a55c8-d886-4bb1-b991-96c5e9fe910a@isocpp.org> X-Original-Sender: tbfleming@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:36910 Archived-At: ------=_Part_12615_215957504.1518570196677 Content-Type: multipart/alternative; boundary="----=_Part_12616_1502680122.1518570196678" ------=_Part_12616_1502680122.1518570196678 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tuesday, February 13, 2018 at 6:55:47 PM UTC-5, Marcin Jaczewski wrote: > > > > On Tuesday, February 13, 2018 at 10:39:35 PM UTC+1, Nicol Bolas wrote: >> >> On Tuesday, February 13, 2018 at 12:18:59 PM UTC-5, floria...@gmail.com= =20 >> wrote: >>> >>> Le mardi 13 f=C3=A9vrier 2018 17:35:49 UTC+1, Nicol Bolas a =C3=A9crit = : >>>> >>>> Because it would never be called. Basically, what you'd need is this= =20 >>>> constructor: >>>> >>>> template >>>> string_view(const char s[N]); >>>> >>>> But you already have this constructor: >>>> >>>> string_view(const char *s); >>>> >>>> An array decays into a pointer. And since the pointer constructor is= =20 >>>> not a template, it is considered a better match than the array version= .. And=20 >>>> therefore, any ltieral you pass will go through the pointer version ra= ther=20 >>>> than the array template. >>>> >>>> And it should be noted that this has nothing to do with being a=20 >>>> literal. If you used a `const char[]` variable, it *still* would=20 >>>> prefer the pointer version due to array->pointer conversion. So this i= s not=20 >>>> a case of "string literals are broken now". >>>> >>> >>> How can you say that preferring a lossy conversion over a lossless one= =20 >>> is not broken? (Here, we lose the length information) >>> >> >> Because the "lossy conversion" part being preferred has nothing to do=20 >> with them being string literals. The lossy conversion is not the=20 >> literal-to-array conversion; it's the array-to-pointer conversion. >> >> You're complaining about the wrong problem. >> >> This make it impossible to work with string literal because they simply= =20 >>> don't exist in the language. This is why I said string literals are bro= ken. >>> =20 >>> >>>> But there's no "fix" for this, since any array->pointer "fix" would be= =20 >>>> both wildly incompatible with C and break tons and tons of code. So yo= u can=20 >>>> either accept the language and work with what we have, or rail against= it. >>>> >>> >>> Ok it's not possible to fix array decay because of backward=20 >>> compatibility, but it is still possible to fix string literals if we ma= ke=20 >>> them something that is not an array. >>> >> >> Why would changing the behavior of string literals be any more backwards= =20 >> compatible than changing the behavior of arrays? There's lots of code ou= t=20 >> there that works with C++'s string literal rules. Can you find a way to= =20 >> change those rules without breaking their code? >> >> Let me give you a simple case: `decltype("a string literal")` is an arra= y=20 >> type. Therefore, any BC change will have to leave it as an array type. S= o=20 >> what rules would you change to fix the problem you want fixed without=20 >> changing the result of that `decltype`? >> >> So I rail against those defects in order to be heard, and maybe, at some= =20 >>> point, they will be fixed. >>> >> >> Yeah, that's not how this works. You can "rail against those defects" al= l=20 >> you like, but unless you're willing to actually work on it (ie: finding = a=20 >> solution that doesn't break the world and getting it through the=20 >> committee), it will not get fixed. Or you manage to convince someone who= 's=20 >> actually willing to put in said work to do so. >> >> If this is not the place to speak out loud about those defects, then=20 >>> where should we go? >>> >>> But don't get me wrong, when I code, I work with what I have, and I=20 >>> accept the language as it is. >>> =20 >>> >>>> >>>> It's funny how the more I dig in C++, the more bulky it appears to be= =20 >>>>> just because of these very small annoyances. >>>>> =20 >>>>> >>>>>> >>>>>> It's a 3 step process; let's not interfere in that. >>>>>> =20 >>>>>> >>>>>>> We could have exatcly the situation with string interpolation: >>>>>>> auto s =3D std::concat(F"{str1}{str2}{str3}"); >>>>>>> // would be equivalent to >>>>>>> auto s =3D F"{str1}{str2}{str3}"s; >>>>>>> >>>>>>> I don't see why allowing UDL to work like that would decrease=20 >>>>>>> usability as we could always use regular functions. >>>>>>> >>>>>> >>>>>> Because you can't do this: >>>>>> >>>>>> std::concat(F"some string {variable} other string"sv); >>>>>> >>>>>> Under my system, the UDL employed here allows you to decide how to= =20 >>>>>> process each of the literal fragments. The UDL applies to the parts = of the=20 >>>>>> literal that are actually strings. So `concat` would get `string_vie= w`s,=20 >>>>>> rather than `const char[X]` parameters. >>>>>> >>>>>> Under your system, the processing of the literal fragments is=20 >>>>>> controlled entirely by the system that computes the aggregation. >>>>>> >>>>> >>>>> Let's sum up, string literals are broken today. So we should probably= =20 >>>>> try to solve this big issue before trying to see how we can cripple= =20 >>>>> string_interpolation in order to fit in current-ish C++. >>>>> >>>> >>>> I fail to see why applying a UDL to the literal fragments rather than= =20 >>>> the interpolation aggregation operation should be considered "cripplin= g"=20 >>>> string interpolation. >>>> >>>> Whatever breakage you see in literals isn't standing in the way of=20 >>>> string interpolation. It's just standing in the way of string interpol= ation=20 >>>> working the way *you* want it to. >>>> >>> >>> Because string interpolation is dealing with string literals, >>> >> >> Why does it have to be? If constexpr strings are in the future, it'd be= =20 >> really nice if string interpolation were defined in such a way that it= =20 >> could be used on them. Tying interpolation to literals is not=20 >> forward-thinking. >> >> if those literals are broken (and they are), how can we have a proper=20 >>> string interpolation? >>> >> >> Because any "brokenness" of string literals has no effect on our ability= =20 >> to use string interpolation. If you want sized strings for those string= =20 >> fragments, that's what the `sv` suffix is for. >> >> Literal issues only are a problem for string interpolation because you= =20 >> believe that the suffix ought to be able to define the aggregation=20 >> operation. If you stop believing that, then all of a sudden, your proble= m=20 >> with string literals becomes a non-issue for interpolation. >> >> It should also be noted that this: >> >> template >> void foo(const T& t); >> >> foo("an array"); >> >> The call to `foo` will deduce `T` to be `char[9]`. So a variadic templat= e=20 >> function that takes the results of string interpolation will get sized= =20 >> array types, not pointers. >> >> Note that this doesn't invalidate anything I said. The point of doing=20 >> `F"blah {variable} blah"sv` is not necessarily because you need them to= =20 >> keep the size around. Using `string_view` has many other advantages, wit= h=20 >> its member functions, `operator<<` overloads, and the like. So wanting t= o=20 >> apply `sv` to each of the fragments is a perfectly reasonable operation. >> >> Also, `string_view` is a lot more convenient to use than an array of=20 >> characters. >> >> You said: >>> >>>> The point of that discussion was a comment someone made about doing=20 >>>> template metaprogramming on string literals. To do that, you need a wa= y to=20 >>>> access each literal as a distinct type, some `string_literal>>> 'h', 'a', 'r'>` type. And only a UDL applied to each fragment can perf= orm=20 >>>> that kind of synthesis. >>>> >>> >>> UDL is the only way to do it only because string literals are broken. I= f=20 >>> we had proper string literals, it should be possible to do it simply wi= th=20 >>> regular functions. >>> >> >> No, it would not. Even if a string literal had a non-array type with a= =20 >> stored size, each literal value would still not have its own distinct=20 >> *type*. Even if the size is a template argument, two literals can store= =20 >> different characters while still having the same size. And you cannot do= =20 >> type-based metaprogramming without having a 1:1 mapping between value an= d=20 >> type. >> >> Remember: while UDL's *can* take strings as a sequence of character=20 >> template parameters, there's a good reason why they aren't *required* to= =20 >> do so. We don't want to force that onto everybody, and a non-"broken"=20 >> string literal system would not force that on people. >> >> So even with your approach, broken string literals are a problem for=20 >>> string interpolation. Just not at the same place. >>> >>> I'm not sure if my approach is the right one (it's probably not), but= =20 >>> most of your arguments stand only because string literal are broken=20 >>> (otherwise, it would have been simple to do the same with my approach t= oo). >>> >>> My point is: yes your approach makes it easier with current C++, but we= =20 >>> shouldn't go for something that works quite well with current C++, but= =20 >>> something that will work very well with future C++. >>> That's why I think it's better to first fix string literals. And then= =20 >>> have string interpolation right the first time. >>> >>> And btw, if string literals are fixed, string interpolation could be=20 >>> made a library solution only ( with a different but reasonable syntax). >>> >> >> It's impossible to do that. String interpolation, at its core, is about= =20 >> taking the contents of a string and applying them in some way to the cod= e=20 >> *around* that string. A library solution cannot possibly do that. >> >> Oh sure, a `constexpr` function could do the parsing. But then what? I'm= =20 >> fairly certain that no static reflection proposal provides a mechanism t= o=20 >> turn a string into a reference to a local variable. And even if they did= ,=20 >> the location where you're doing that conversion wouldn't have that varia= ble=20 >> in scope (since it's in a function call), so it couldn't possibly work. >> >> PS: I think it would be preferable to stop the discussion here, as it=20 >>> becomes more and more off-topic. >>> >> >> But what if we don't agree that string interpolation needs better=20 >> literals? >> >> Your premise is essentially that my suggested syntax is some kind of=20 >> compromise, that if literals weren't "broken" the way you feel that they= =20 >> are, then it would *clearly* be correct to have UDLs applied to=20 >> aggregation rather than to the individual fragments. >> >> I don't agree with that premise. Whether literals are good or broken is = a=20 >> side issue. Even if we had perfect literals, I would *still* rather UDLs= =20 >> be focused on individual string literal manipulation rather than string= =20 >> interpolation aggregation. >> > =20 > > After some toughs I come to conclusion that mixing interpolation with UDL= =20 > is limiting thing and this is good thing. Why? Because beside good things= =20 > it limit bad things too. > I start from high metaprograming starting point where I made all trader= =20 > offs to make it work, you start from basic usage and use opposite options= .. > As consequence all my example of use of string interpolation become=20 > unusable in your approach. > > We can start with sql, you suggest that version: > db.exec(F"some sql stuff {var1} more sql {var2};"); > > I can quote someone: "Have we learned nothing from Little Bobby Tables?",= =20 > how you want disquisition between `const char*`s parameters? > I did not had this problem because I can limit how parameters are pass to= =20 > UDL and I can relay on it. > One way to avoid it is add new literal that will help with that but in=20 > some corner cases it could still break. > > db.exec("select sth"_sql); > db.exec(F"select sth when {name}"_sqlp); //as you point outs, "select x"= =20 > is not sql, we need diffrent postfix. > tuple(F"{name1}{name2}"); //this is `tuple` or= =20 > `tuple`? > tuple(F"{name1} {name2}"); //same type as above? > translate(F"With {part} to {change}? Can I {change}{order} in any way?",= =20 > "fr"); //BTW "fr" is part of interpolated string from perspective of this= =20 > function > In my case all this things can be enclosed in UDL and will not leak=20 > outside. > > Another problem is that even if your version is more flexible you still= =20 > repeat in multiple of place usage of specialization point functions=20 > otherwise you cant use interpolation without it, in my version you only= =20 > would need use them in UDL. > > Probably without lot of limitation, many quirks will prevent any serous= =20 > metaprograming. I'm inclined to thinking that whole idea will not go far. > > btw > f(F"T{{a}}"); //is `f("T{{a}}")` or `f("T", {a})`? > Where both version could compile. Probably safer would be follow JS=20 > version where we it use `${` to start interpolation. > > This could stop Little Bobby Tables: f(F"{a}{b}"); could translate to f("", a, "", b, ""); arguments 0, ..., 2n are always literals and 1, ..., 2n-1 are always=20 expressions. f(F"T{{a}}"); would be=20 f("", {a}, "") --=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/c753942d-be11-4cc0-bde1-7f71b6184367%40isocpp.or= g. ------=_Part_12616_1502680122.1518570196678 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tuesday, February 13, 2018 at 6:55:47 PM UTC-5, Marcin = Jaczewski wrote:


On Tuesday, February 13, 2018 at 10:39:35 PM UTC+1, Nicol Bolas = wrote:
On Tuesday, = February 13, 2018 at 12:18:59 PM UTC-5, floria...@gmail.com wrote:
Le mardi 13 f=C3=A9v= rier 2018 17:35:49 UTC+1, Nicol Bolas a =C3=A9crit=C2=A0:
Because it would never be call= ed. Basically, what you'd need is this constructor:

templat= e<si= ze_t N>
string_view(const char s[N]);

But you already have this constructor= :

string_view(const char *s);

An array decays into a pointer. = And since the pointer constructor is not a template, it is considered a bet= ter match than the array version. And therefore, any ltieral you pass will = go through the pointer version rather than the array template.

And i= t should be noted that this has nothing to do with being a literal. If you = used a `const char[]` variable, it still would prefer the pointer ve= rsion due to array->pointer conversion. So this is not a case of "s= tring literals are broken now".

<= /div>
How can you say that preferring a lossy conversion over a lossles= s one is not broken? (Here, we lose the length information)
=

Because the "lossy conversion" part being p= referred has nothing to do with them being string literals. The lossy conve= rsion is not the literal-to-array conversion; it's the array-to-pointer= conversion.

You're complaining about the wrong problem.

=
<= div>This make it impossible to work with string literal because they simply= don't exist in the language. This is why I said string literals are br= oken.
=C2=A0
But there's no "fix" for this, since any array= ->pointer "fix" would be both wildly incompatible with C and b= reak tons and tons of code. So you can either accept the language and work = with what we have, or rail against it.

Ok it's not possible to fix array decay because = of=20 backward compatibility, but it is still possible to fix string literals=20 if we make them something that is not an array.

Why would changing the behavior of string literals be any more backwa= rds compatible than changing the behavior of arrays? There's lots of co= de out there that works with C++'s string literal rules. Can you find a= way to change those rules without breaking their code?

Let me give = you a simple case: `decltype("a string literal")` is an array typ= e. Therefore, any BC change will have to leave it as an array type. So what= rules would you change to fix the problem you want fixed without changing = the result of that `decltype`?

So I rail against those defects in order to = be heard, and maybe, at some point, they will be fixed.

Yeah, that's not how this works. You can "rail again= st those defects" all you like, but unless you're willing to actua= lly work on it (ie: finding a solution that doesn't break the world and= getting it through the committee), it will not get fixed. Or you manage to= convince someone who's actually willing to put in said work to do so.<= br>
= If this is not the place to speak out loud about those defects, then where = should we go?

But don't get me wrong, when= I code, I work with what I have, and I accept the language as it is.
=C2=A0

=
It's funny how the more I dig in C++, the more bulky it appears to= be just because of these very small annoyances.
=C2=A0
=

It's = a 3 step process; let's not interfere in that.
=C2=A0
We could ha= ve exatcly the situation with string interpolation:
auto s =3D= std::<= span style=3D"color:#000">concat(<= span style=3D"color:#000">F"{str1}{s= tr2}{str3}");
// would be equivalen= t to
auto s =3D F&= quot;{str1}{str2}{str3}"s;
=

I don't see why allowing UDL to work like that would d= ecrease usability as we could always use regular functions.
=

Because you can't do this:

std::concat<= span style=3D"color:#660">(F"some string {variable} other string"= sv);

Under my system, the UDL employed here allows you to de= cide how to process each of the literal fragments. The UDL applies to the p= arts of the literal that are actually strings. So `concat` would get `strin= g_view`s, rather than `const char[X]` parameters.

Under your system,= the processing of the literal fragments is controlled entirely by the syst= em that computes the aggregation.

Let's sum up, string literals are broken today. So we should probabl= y try to solve this big issue before trying to see how we can cripple strin= g_interpolation in order to fit in current-ish C++.

I fail to see why applying a UDL to the literal fragments rat= her than the interpolation aggregation operation should be considered "= ;crippling" string interpolation.

Whatever breakage you see in = literals isn't standing in the way of string interpolation. It's ju= st standing in the way of string interpolation working the way you w= ant it to.

Because string i= nterpolation is dealing with string literals,
=
Why does it have to be? If constexpr strings are in the future, it'= d be really nice if string interpolation were defined in such a way that it= could be used on them. Tying interpolation to literals is not forward-thin= king.

if those literals are broken (and they are), how can we have a proper= string interpolation?

Because any "b= rokenness" of string literals has no effect on our ability to use stri= ng interpolation. If you want sized strings for those string fragments, tha= t's what the `sv` suffix is for.

Literal issues only are a probl= em for string interpolation because you believe that the suffix ought to be= able to define the aggregation operation. If you stop believing that, then= all of a sudden, your problem with string literals becomes a non-issue for= interpolation.

It should also be noted that this:

templat= e<ty= pename T>
void foo(const T& t);<= br>
foo("an array");

The call to `foo` will= deduce `T` to be `char[9]`. So a variadic template function that takes the= results of string interpolation will get sized array types, not pointers.<= br>
Note that this doesn't invalidate anything I said. The point of = doing `F"blah {variable} blah"sv` is not necessarily because you = need them to keep the size around. Using `string_view` has many other advan= tages, with its member functions, `operator<<` overloads, and the lik= e. So wanting to apply `sv` to each of the fragments is a perfectly reasona= ble operation.

Also, `string_view` is a lot more convenient to use t= han an array of characters.

You said:
The point of that discussion was a commen= t someone made about doing=20 template metaprogramming on string literals. To do that, you need a way=20 to access each literal as a distinct type, some `string_literal<char, 'c', 'h', 'a', 'r'>` type. And only a U= DL applied to each fragment=20 can perform that kind of synthesis.

U= DL is the only way to do it only because string literals are broken. If we = had proper string literals, it should be possible to do it simply with regu= lar functions.

No, it would not. Even if a= string literal had a non-array type with a stored size, each literal value= would still not have its own distinct type. Even if the size is a t= emplate argument, two literals can store different characters while still h= aving the same size. And you cannot do type-based metaprogramming without h= aving a 1:1 mapping between value and type.

Remember: while UDL'= s can take strings as a sequence of character template parameters, t= here's a good reason why they aren't required to do so. We d= on't want to force that onto everybody, and a non-"broken" st= ring literal system would not force that on people.

So even with your appro= ach, broken string literals are a problem for string interpolation. Just no= t at the same place.

I'm not sure if my approa= ch is the right one (it's probably not), but most of your arguments sta= nd only because string literal are broken (otherwise, it would have been si= mple to do the same with my approach too).

My poin= t is: yes your approach makes it easier with current C++, but we shouldn= 9;t go for something that works quite well with current C++, but something = that will work very well with future C++.
That's why I think = it's better to first fix string literals. And then have string interpol= ation right the first time.

And btw, if string= literals are fixed, string interpolation could be made a library solution = only ( with a different but reasonable syntax).

It's impossible to do that. String interpolation, at its core, is= about taking the contents of a string and applying them in some way to the= code around that string. A library solution cannot possibly do that= ..

Oh sure, a `constexpr` function could do the parsing. But then wha= t? I'm fairly certain that no static reflection proposal provides a mec= hanism to turn a string into a reference to a local variable. And even if t= hey did, the location where you're doing that conversion wouldn't h= ave that variable in scope (since it's in a function call), so it could= n't possibly work.

PS: I think it would be preferable to sto= p the discussion here, as it becomes more and more off-topic.

But what if we don't agree that string interpol= ation needs better literals?

Your premise is essentially that my sug= gested syntax is some kind of compromise, that if literals weren't &quo= t;broken" the way you feel that they are, then it would clearly= be correct to have UDLs applied to aggregation rather than to the individu= al fragments.

I don't agree with that premise. Whether literals = are good or broken is a side issue. Even if we had perfect literals, I woul= d still rather UDLs be focused on individual string literal manipula= tion rather than string interpolation aggregation.
=C2=A0

After some toughs I come to conclusion that mixing i= nterpolation with UDL is limiting thing and this is good thing. Why? Becaus= e beside good things it limit bad things too.
I start from high metaprog= raming starting point where I made all trader offs to make it work, you sta= rt from basic usage and use opposite options.
As consequence all my exam= ple of use of string interpolation become unusable in your approach.
We can start with sql, you suggest that version:
db.exec(F"some sql stuff {var1} more sql {var2};");

I can quote someone: &q= uot;Have we learned nothing from Little Bobby Tables?", how you want d= isquisition between `const char*`s parameters?
I did not had this proble= m because I can limit how parameters are pass to UDL and I can relay on it.=
One way to avoid it is add new literal that will help with that but in = some corner cases it could still break.

db.exec("select sth"_sql);
db.exec(F"select sth w= hen {name}"_sqlp); //as you point outs, "select x" is not sql, we need d= iffrent postfix.
tuple(F"{name1}{name2}");= //this= is `tuple<const char*, const char*>` or `tuple<const char*, const= char*, const char*, const char*, const char*>`?
tuple(F"{name1} {name2}"= ); //same type as above?
translate(F"With {part} to {c= hange}? Can I {change}{order} in any way?", "fr"); //BTW "fr" is part o= f interpolated string from perspective of this function
In my case all this things ca= n be enclosed in UDL and will not leak outside.

Another problem is t= hat even if your version is more flexible you still repeat in multiple of p= lace usage of specialization point functions otherwise you cant use interpo= lation without it, in my version you only would need use them in UDL.
Probably without lot of limitation, many quirks will prevent any serous m= etaprograming. I'm inclined to thinking that whole idea will not go far= ..

btw
f(F"T{{a}}"); //is `f("T{{a}}")` or `f("T", {= a})`?
Where = both version could compile. Probably safer would be follow JS version where= we it use `${` to start interpolation.


This could stop Little Bobby Tables:

<= div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bo= rder-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wor= d-wrap: break-word;">
f(F"{a}{b}");

<= /div>
could translate to

f("", a, "", b, "");


arguments 0, ..., 2n are always literals and 1, ..., 2n-1 are always exp= ressions.

f(F&qu= ot;T{{a}}");

would be=C2=A0

f("", {= a}, "")


--
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/c753942d-be11-4cc0-bde1-7f71b6184367= %40isocpp.org.
------=_Part_12616_1502680122.1518570196678-- ------=_Part_12615_215957504.1518570196677-- .