220 36909 <589a55c8-d886-4bb1-b991-96c5e9fe910a@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: Tue, 13 Feb 2018 15:55:47 -0800 (PST) Lines: 701 Approved: news@gmane.org Message-ID: <589a55c8-d886-4bb1-b991-96c5e9fe910a@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> <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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_11091_867363171.1518566147732" X-Trace: blaine.gmane.org 1518566041 3596 195.159.176.226 (13 Feb 2018 23:54:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 13 Feb 2018 23:54:01 +0000 (UTC) Cc: florian.csdt@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDDLTAGNTIBBBBPWRXKAKGQEDNJDYDY@isocpp.org Wed Feb 14 00:53:57 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 1elkOO-0008Ls-Rv for gclcip-std-proposals@m.gmane.org; Wed, 14 Feb 2018 00:53:45 +0100 Original-Received: by mail-ua0-f197.google.com with SMTP id b45sf13440423uad.10 for ; Tue, 13 Feb 2018 15:55:50 -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=l1TIFaK8aHtO8Ckf+7jbhNmJ3hdtFqjLk2r38kgy9o0=; b=q+1FZq89yZLLzu05ojmIixVjMD01YvUUjZXI0iUXvbeVo/JgQjG90tVS49mMFyewYL SbJt2RUs4ec6fpLJ6cd0pzWNS/O9lCh+2Q/vFsj2AKNP46iLwJ0QT/0+2vdv+WqkaJU0 XLBpbdq5E0nw7eprWfJ5kGPiqXrG8OdF6x0LUFZB2YOhpuHB0yLVc/itbOHyMAIpW76P Ep6cqy2fwrFBmvlYoTopPkv95dHrnHLE/L7hF1QYs2q/OZwzz5fo/piAJZc9VsC3M8ti zEYCNnSDjKKapLnoUAwQ+FWfC+VptqPdxhLDUkQV9AF0vF8DninVTlmDnQAZiEPkxrvS 7cxw== 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=l1TIFaK8aHtO8Ckf+7jbhNmJ3hdtFqjLk2r38kgy9o0=; b=TDgFQ0g55iFLc/myKlRvogUvsegVfHo1Wxl/gQC4yTVJXARDBMn3um2mTtxRcDowRg wI/6LEpHUKZ1x1btW2idaq5GLZT6U8/NWQjxP1s14A8/HTowpUszbGgI30+ERUilqtf6 +DD0yKoEImkkn6t1Tr1mn6ir+y9SwTa+mySfDGcSE/nVHlkBMHh9nlgosTK/jWpM7cx1 i3f1jDpa6YNJ0ZcUwwkGw9baNzURf8RGrGhtPC5anKjqR4wCPuPwxNYPi/x50qDE2zW7 HnBis+FuFQqcz0Xe7z9nPZDpTrhKKA792M0Xldvt1JzqJDvVvkAqzTStRvDGIclIFtoM +JpA== 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=l1TIFaK8aHtO8Ckf+7jbhNmJ3hdtFqjLk2r38kgy9o0=; b=NyoRDL+GBL9pfjAUh4lLqvss2URSsLGTzL8uS4FXw3jVZpqIEcqe//Zdl/71Ja4XWr Di+XGlR1KSbnlPlJOJdDtAczyA6iHypqvSsb1UxlkMk76bfkYXOKOkGYf/ShPFnqqiE9 VatfdPziRkVjSxMjKtfeu4rToNpOLScIF23ng3wBeP3pLf/eraEBHMdbaPKfr6HFosn4 LzYFVG7M+aDKxtTE+1C+q2cN8jpnI/RGKPUvMZHdLsVHmXBi/9M6Kfr65yP1ZDFPXEb+ kOEARlv95RzL49xTv+ofOo8+XFAEw9voBTz6OHBm0PWVQe+W17eWyk70qVGWbmHVO0a4 pMGg== X-Gm-Message-State: APf1xPCoXuE9FzC1Ps5+EY99XAeGisRTkjs+d0UTZHn9Sjpn9BGXbrgY MqMhJ0AdiAtOZeBzLARSOEilKA== X-Google-Smtp-Source: AH8x2270XR2AKsR/DlLc0wCcqxecyHCO4fvXhCSIQv6hycyDy72+cKA7XSkPFX8REblkWZZ0W4AaNw== X-Received: by 10.176.49.84 with SMTP id e20mr1494507uam.11.1518566150443; Tue, 13 Feb 2018 15:55:50 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.178.134 with SMTP id b128ls8939794vkf.7.gmail; Tue, 13 Feb 2018 15:55:48 -0800 (PST) X-Received: by 10.31.185.13 with SMTP id j13mr175242vkf.8.1518566148589; Tue, 13 Feb 2018 15:55:48 -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:36909 Archived-At: ------=_Part_11091_867363171.1518566147732 Content-Type: multipart/alternative; boundary="----=_Part_11092_1010458152.1518566147733" ------=_Part_11092_1010458152.1518566147733 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 no= t=20 >>> 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 rat= her=20 >>> than the array template. >>> >>> And it should be noted that this has nothing to do with being a literal= ..=20 >>> If you used a `const char[]` variable, it *still* would prefer the=20 >>> pointer version due to array->pointer conversion. So this is not a case= of=20 >>> "string literals are broken now". >>> >> >> How can you say that preferring a lossy conversion over a lossless one i= s=20 >> not broken? (Here, we lose the length information) >> > > Because the "lossy conversion" part being preferred has nothing to do wit= h=20 > 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 brok= en. >> =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 you= 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 mak= e=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 out= =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 array= =20 > type. Therefore, any BC change will have to leave it as an array type. So= =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" all= =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 wher= e=20 >> 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 o= f the=20 >>>>> literal that are actually strings. So `concat` would get `string_view= `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 "crippling= "=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 interpola= tion=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 problem= =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 template= =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, with= =20 > its member functions, `operator<<` overloads, and the like. So wanting to= =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 way= 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 perfo= rm=20 >>> that kind of synthesis. >>> >> >> UDL is the only way to do it only because string literals are broken. If= =20 >> we had proper string literals, it should be possible to do it simply wit= h=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 and= =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 to= o). >> >> 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 mad= e=20 >> 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 code= =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 to= =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 variab= le=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 literal= s? > > 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 some= =20 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" is= =20 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 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 version= =20 where we it use `${` to start interpolation. --=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/589a55c8-d886-4bb1-b991-96c5e9fe910a%40isocpp.or= g. ------=_Part_11092_1010458152.1518566147733 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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...@g= mail.com wrote:
Le mardi 13 f=C3=A9vrier 2018 17:35:49 UTC+1, Nicol Bolas a =C3=A9crit=C2= =A0:
Because i= t would never be called. Basically, what you'd need is this constructor= :

template<size_t N>
string_view(const char s[N]);

But you already ha= ve this constructor:

<= div>string_view(const= char <= /span>*s);

An array decays= into a pointer. And since the pointer constructor is not a template, it is= considered a better match than the array version. And therefore, any ltier= al you pass will go through the pointer version rather than the array templ= ate.

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

How can you say that preferring a lossy conversi= on over a lossless one is not broken? (Here, we lose the length information= )

Because the "lossy conversion&q= uot; part being preferred has nothing to do with them being string literals= .. The lossy conversion is not the 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 be= cause they simply don't exist in the language. This is why I said strin= g literals are broken.
=C2=A0
But there's no "fix" for this= , since any array->pointer "fix" would be both wildly incompat= ible with C and break tons and tons of code. So you can either accept the l= anguage and work with what we have, or rail against it.

Ok it's not possible to fix arr= ay 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: "Have we learned nothing from Little Bobby Ta= bles?", how you want disquisition between `const char*`s parameters?I did not had this problem 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.

<= div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 1= 87, 187); border-style: solid; border-width: 1px; overflow-wrap: break-word= ;" class=3D"prettyprint">
db= .exec("select sth"_sql);
db.exec(F&quo= t;select sth when {name}"_sqlp); //= as you point outs, "select x" is not sql, we need diffrent postfi= x.
tupl= e(<= span style=3D"color: #000;" class=3D"styled-by-prettify">F"{name1}{name2}"<= /span>); //this is `tuple<const ch= ar*, const char*>` or `tuple<const char*, const char*, const char*, c= onst char*, const char*>`?
tuple(F= "{name1} {name2}"); = //same type as above?
translate(F&quo= t;With {part} to {change}? Can I {change}{order} in any way?", "fr"); //BTW "fr" is part of interpolated strin= g from perspective of this function
In my case all this = things can be enclosed in UDL and will not leak outside.

Another pro= blem is that even if your version is more flexible you still repeat in mult= iple of place usage of specialization point functions otherwise you cant us= e interpolation without it, in my version you only would need use them in U= DL.

Probably without lot of limitation, many quirks will prevent any= serous metaprograming. I'm inclined to thinking that whole idea will n= ot 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.

--
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/589a55c8-d886-4bb1-b991-96c5e9fe910a= %40isocpp.org.
------=_Part_11092_1010458152.1518566147733-- ------=_Part_11091_867363171.1518566147732-- .