220 36911 article Path: news.gmane.org!.POSTED!not-for-mail From: Jake Arkinstall Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: String interpolation Date: Wed, 14 Feb 2018 01:25:49 +0000 Lines: 808 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/alternative; boundary="94eb2c04f868cc4418056521fdc6" X-Trace: blaine.gmane.org 1518571485 595 195.159.176.226 (14 Feb 2018 01:24:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 14 Feb 2018 01:24:45 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDCZX3WUUQFRBH5AR3KAKGQESAPZMTY@isocpp.org Wed Feb 14 02:24:40 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f72.google.com ([209.85.218.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1elloC-0007Zr-NA for gclcip-std-proposals@m.gmane.org; Wed, 14 Feb 2018 02:24:29 +0100 Original-Received: by mail-oi0-f72.google.com with SMTP id d135sf10204887oib.15 for ; Tue, 13 Feb 2018 17:26:34 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1518571594; cv=pass; d=google.com; s=arc-20160816; b=T+/083Dy6wP+JrY8BDlKw7KwYGqA+Yx2CEc+6xlSAQbEKXuu1TcnZfNTmKUpsFzmxR dsaOrq2Weld2C1Dswltg6KPVjpV4XxbXFHuEi0EUP3jnrlXC69xLCtL4AGT9byd+t88/ n6z5EuHwXc3p/PJjw7Zg+E617ZEu2phIGsNBmoejYwDGRHzAmtgnyq0UR4OGgnDZPhBW VvP/GGE8mVKzRUUyoBTVPNUA52BwTfJigHNBYS83owdaoVSq9NIvdB7C9DPKIafaFC3D w375cCgvqSp6NdTf4fuMgBdgQVmzqw5oDyKnsaktjQ9GHl7qV4Fo9dIgp2DYCvepEn9U F9ZQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=Y4L0xcRlF7JeoOGB525gCWL7eg8g4pX+omH0ENOzhig=; b=wKTk01gznNGtoXUK/CEBEwOUiF2fDgxfHUYNLlkNDZfupiS/1QrnI1ZNHb5LgBySJ6 t7XQu7l19JmreXQ64tIihDXJWQlKEFgXU4q3ZHB5lXXw3KQmEb91GF2QZUZakWXeQVOV cp4qIJC216F0fpYNnFVsDa1ixeLqditrdIkRpJsPL05xR0a2RM7rkNyyNc5qKYoB4wCS dnXLdg5qKpQlNfsAympUDAKskj5weLZ3RbsCgO+MG/geADXsT9O5h0C5ZbhWbssLfvri qx0OI9UNRUx/pJmf2VHYQcqCpYlbpTjm0u7itV+tR5PGmq7JgZije1WQtrVhPo/tBU87 dfbQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Y45OyJkJ; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Y4L0xcRlF7JeoOGB525gCWL7eg8g4pX+omH0ENOzhig=; b=CjnaYfsrr54cKcDPERcBo6kb2KQQckAGCPCA5QbfKkIEAZf1n8tmnoAZMACagT+hMA lg3dnJ+Ilr+zGkBOKEpZUbqTamp+iTBbMNNnIXvBOAd1WiSQIl3bQeq2rNu1hjvexa2J 4zQOMDgJMAAcLSn1gHVaDrrPz2RbuCGIQE2jBUnS6iXeFQpV7JNN8JlBbURf8mFLkEu5 tovm+Whkx3ZUzZtpw2ysqW3BzBOc7VRbC5Hwt7AHxtKtM2gxavXwnrldIXdKW5GTSwWw Eq40A2dY6M/g+inpFBrmUU0QN3qHFskBbf391QSw5xamUCdsCW2t1zF8/efNutKhDewo 2fIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Y4L0xcRlF7JeoOGB525gCWL7eg8g4pX+omH0ENOzhig=; b=MVyKYODcXbdG1nljIYa0b28YOx3XggUKb+D/jp7esfXPv9pobqjxVg7YP2X36MekUs 6G4uKvmbK1iLqzuzeaWf5yexDy5FLbnvtRITm9m0Hl9rP96DaUumFyLFu8gEhN90Vi6y 3xPycs1aTsciTQAt7D81xtOxeqOR4oYvE0adK0iNsfrgbcU5e2Kc2KKDjglbhMmLQT5Y kDZNXKgrOaGcBWODLm08QL5vljNpSchh4QQOQUmYQnSY9qSdHJQwH5CCgswqja8KUX90 IPdVF4DjkbI30lViETsv0/VcIwvLechsNYPwtLjkJmIbc/I6yMNRl4EQNUN34uGQBpG0 NA3g== X-Gm-Message-State: APf1xPAjDl+0n1BCL4i6fLb9UC1TXlO8IDNxj8ABYk8pN3lR0AA/3hu9 PWVDa/PJGduYaXTmiqSgLIp9MA== X-Google-Smtp-Source: AH8x224I2jGi02YQ6Ghbr8KIHcBGIPbR9wTDuqm5ihWTmISzjVcp21BthvOEb4QcsmL5bVZX3DYQKw== X-Received: by 10.202.18.17 with SMTP id 17mr1554006ois.48.1518571594325; Tue, 13 Feb 2018 17:26:34 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.84.78.148 with SMTP id c20ls841143oiy.12.gmail; Tue, 13 Feb 2018 17:25:50 -0800 (PST) X-Received: by 10.202.178.5 with SMTP id b5mr2194849oif.152.1518571550606; Tue, 13 Feb 2018 17:25:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518571550; cv=none; d=google.com; s=arc-20160816; b=KdLKT1Dsd36EJ+SwO3VcbiaXHyRX5Fo3GvObPuZkkKKGG8eJEvsFcg/LxkbiVHBkOn aIS4uR1vP3df6NCJ78KBTXp6CnClEqQ9j+1kt2kf+IGfSe5zcmf+loIOF7RuC1xO2PF/ KEq9bfpgQhpcIlEuvfKIPNfYoDT4C+8GDkT/+wRaWFyMqej+VeDDzSPgLNeUcbJKkcY9 onGg+Vi6J9Z4oiofwMK4WvMOdVWVXGoapS4xhAQPIgeXQo456IGZdXZSooOVdNva8Jnu sShwBJZDZML5kYSDoi0lVTPGVRlLNekiVU6wU1/T6+ZmR41LQTfBYRaPccbrBiwnqOjq iG+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=aUppi0OP1BdVn8g0fJ84RMJe0S8maAjXOxw2cnhcfsw=; b=uZn5kuVaVdKhLERDfpCdgK45cF81TiR/Y5UkzA84KteSoSFPCCN05bt9q6i2vrk9E/ BHURCfk3QOPdsi+B3YvKkkNJTxeVTt+ckSRVf1EKJUMSbayTc6gyI/SVlUE+mQnTaAzJ a6TFAld1iN0a67qI+8u1dtwe/86QI3RZa/31eQdU0//DCTFVZGHc58DGFEHc/y36txJM cYmD0nsEk3waEY4KbIQ9zN4PDWDJJHCxvG8jevo7SdHDu7Xv2sWCGNvxP3T5gw1B9rbo ZcLyUBzbqc6K4OHZIv956HxQdWQdQfs3CbqXky4XJWOeDy1tSkeCR35+Eiv3Qz1A2d0W KrhQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Y45OyJkJ; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id 44sor4891257ote.74.2018.02.13.17.25.50 for (Google Transport Security); Tue, 13 Feb 2018 17:25:50 -0800 (PST) Received-SPF: pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; X-Received: by 10.157.6.194 with SMTP id 60mr781735otx.288.1518571549900; Tue, 13 Feb 2018 17:25:49 -0800 (PST) Original-Received: by 10.168.151.129 with HTTP; Tue, 13 Feb 2018 17:25:49 -0800 (PST) Original-Received: by 10.168.151.129 with HTTP; Tue, 13 Feb 2018 17:25:49 -0800 (PST) In-Reply-To: X-Original-Sender: jake.arkinstall@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Y45OyJkJ; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:36911 Archived-At: --94eb2c04f868cc4418056521fdc6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I certainly see some benefit of string literals separating parameters for ease, but at the same time I can imagine that there will be some situations where meaningless empty strings complicate matters. It has the potential to be a quirk, rather than a feature. Parsing the parameters in a one by one manner could be a pain; I guess it would involve splitting the handling into two functions - one for literals, one for variables, and each recursively calls the other with the next parameter iff it exists. The alternative is a monad approach. Wrap the literal values in some template literal_string<> and the injected variables in some template injected_variable, or just one of the two (I guess the latter makes more sense). That could get ugly real quick, but it helps distinguish the two. At least then one could use template specialisation to handle the situations differently, without needing to rely on a fixed every-other structure. On 14 Feb 2018 01:03, "Todd Fleming" wrote: > 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=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 >>>>> 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 >>>>> not a template, it is considered a better match than the array versio= n. And >>>>> therefore, any ltieral you pass will go through the pointer version r= ather >>>>> than the array template. >>>>> >>>>> 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 >>>>> prefer 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 conversion over a lossless one >>>> is not broken? (Here, we lose the length information) >>>> >>> >>> Because the "lossy conversion" 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 because they simply >>>> don't exist in the language. This is why I said string literals are br= oken. >>>> >>>> >>>>> But there's no "fix" for this, since any array->pointer "fix" would b= e >>>>> both wildly incompatible with C and break tons and tons of code. So y= ou can >>>>> either accept the language and work with what we have, or rail agains= t it. >>>>> >>>> >>>> Ok it's not possible to fix array decay because of backward >>>> compatibility, but it is still possible to fix string literals if we m= ake >>>> them something that is not an array. >>>> >>> >>> Why would changing the behavior of string literals be any more backward= s >>> compatible than changing the behavior of arrays? There's lots of code o= ut >>> 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 type. 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 som= e >>>> point, they will be fixed. >>>> >>> >>> Yeah, that's not how this works. You can "rail against those defects" >>> all you like, but unless you're willing to actually work on it (ie: fin= ding >>> 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 wh= o's >>> actually willing to put in said work to do so. >>> >>> 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. >>>> >>>> >>>>> >>>>> It's funny how the more I dig in C++, the more bulky it appears to be >>>>>> just because of these very small annoyances. >>>>>> >>>>>> >>>>>>> >>>>>>> It's a 3 step process; let's not interfere in that. >>>>>>> >>>>>>> >>>>>>>> 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 >>>>>>>> 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 >>>>>>> process each of the literal fragments. The UDL applies to the parts= of the >>>>>>> literal that are actually strings. So `concat` would get `string_vi= ew`s, >>>>>>> rather than `const char[X]` parameters. >>>>>>> >>>>>>> Under your system, the processing of the literal fragments is >>>>>>> controlled entirely by the system 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 >>>>>> string_interpolation in order to fit in current-ish C++. >>>>>> >>>>> >>>>> I fail to see why applying a UDL to the literal fragments rather than >>>>> the interpolation aggregation operation should be considered "crippli= ng" >>>>> string interpolation. >>>>> >>>>> Whatever breakage you see in literals isn't standing in the way of >>>>> string interpolation. It's just standing in the way of string interpo= lation >>>>> 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 >>> 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-thinking. >>> >>> if those literals are broken (and they are), how can we have a proper >>>> string interpolation? >>>> >>> >>> Because any "brokenness" of string literals has no effect on our abilit= y >>> to use string interpolation. If you want sized strings for those string >>> fragments, that's what the `sv` suffix is for. >>> >>> Literal issues only are a problem 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 probl= em >>> 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 function that takes the results of string interpolation will g= et >>> sized array types, not pointers. >>> >>> 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 advantages, wi= th >>> its member functions, `operator<<` overloads, and the like. So wanting = to >>> 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 >>> characters. >>> >>> You said: >>>> >>>>> The point of that discussion was a comment someone made about doing >>>>> template metaprogramming on string literals. To do that, you need a w= ay to >>>>> access each literal as a distinct type, some `string_literal` type. And only a UDL applied to each fragment can per= form >>>>> that kind of synthesis. >>>>> >>>> >>>> UDL 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 simpl= y >>>> with regular 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 template argument, two literals can store >>> different characters while still having the same size. And you cannot d= o >>> type-based metaprogramming without having a 1:1 mapping between value a= nd >>> type. >>> >>> Remember: while UDL's *can* take strings as a sequence of character >>> template parameters, there's a good reason why they aren't *required* >>> to do so. We don't want to force that onto everybody, and a non-"broken= " >>> string literal system would not force that on people. >>> >>> So even with your approach, broken string literals are a problem for >>>> string interpolation. Just not at the same place. >>>> >>>> I'm not sure if my approach is the right one (it's probably not), but >>>> most of your arguments stand only because string literal are broken >>>> (otherwise, it would have been simple to do the same with my approach = too). >>>> >>>> My point is: yes your approach makes it easier with current C++, but w= e >>>> shouldn'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 interpolation 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 co= de >>> *around* that string. A library solution cannot possibly do that. >>> >>> Oh sure, a `constexpr` function could do the parsing. But then what? I'= m >>> fairly certain that no static reflection proposal provides a mechanism = to >>> turn a string into a reference to a local variable. And even if they di= d, >>> the location where you're doing that conversion wouldn't have that vari= able >>> 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 >>>> becomes more and more off-topic. >>>> >>> >>> But what if we don't agree that string interpolation needs better >>> literals? >>> >>> Your premise is essentially that my suggested syntax is some kind of >>> compromise, that if literals weren't "broken" the way you feel that the= y >>> are, then it would *clearly* be correct to have UDLs applied to >>> aggregation rather than to the individual 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 would *still* rather >>> UDLs be focused on individual string literal manipulation rather than >>> string interpolation aggregation. >>> >> >> >> After some toughs I come to conclusion that mixing interpolation with UD= L >> is limiting thing and this is good thing. Why? Because beside good thing= s >> it limit bad things too. >> I start from high metaprograming starting point where I made all trader >> offs to make it work, you start from basic usage and use opposite option= s. >> As consequence all my example 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 Tables?"= , >> how you want disquisition between `const char*`s parameters? >> I did not had this problem because I can limit how parameters are pass t= o >> 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 when {name}"_sqlp); //as you point outs, "select x" >> is not sql, we need diffrent postfix. >> tuple(F"{name1}{name2}"); //this is `tuple` or >> `tuple`= ? >> tuple(F"{name1} {name2}"); //same type as above? >> translate(F"With {part} to {change}? Can I {change}{order} in any way?", >> "fr"); //BTW "fr" is part of interpolated string from perspective of >> this 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 >> repeat in multiple of place usage of specialization point functions >> otherwise you cant use interpolation without it, in my version you only >> would need use them in UDL. >> >> Probably without lot of limitation, many quirks will prevent any serous >> 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 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 > expressions. > > f(F"T{{a}}"); > > would be > > f("", {a}, "") > > > -- > You received this message because you are subscribed to the Google Groups > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to std-proposals+unsubscribe@isocpp.org. > To post to this group, send email to std-proposals@isocpp.org. > 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 > > . > --=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/CAC%2B0CCPrAspxkZJXbhJyc9UCXS3FAw3UU0GEvAzURwKG1= -pvoA%40mail.gmail.com. --94eb2c04f868cc4418056521fdc6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I certainly see some benefit of string literals separatin= g parameters for ease, but at the same time I can imagine that there will b= e some situations where meaningless empty strings complicate matters. It ha= s the potential to be a quirk, rather than a feature. Parsing the parameter= s in a one by one manner could be a pain; I guess it would involve splittin= g the handling into two functions - one for literals, one for variables, an= d each recursively calls the other with the next parameter iff it exists.
The alternative is a monad appr= oach. Wrap the literal values in some template literal_string<> and t= he injected variables in some template injected_variable<T>, or just = one of the two (I guess the latter makes more sense). That could get ugly r= eal quick, but it helps distinguish the two. At least then one could use te= mplate specialisation to handle the situations differently, without needing= to rely on a fixed every-other structure.



On 14 Feb 2018 01:03, "Todd Fleming" <tbfleming@gmail.com> wrote:
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=A9vrier 2018 17:35:49 UTC+1, Nicol = Bolas a =C3=A9crit=C2=A0:
Because it would never be called. Basically, what you'd n= eed is this constructor:

template<size_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 i= s not a template, it is considered a better match than the array version. A= nd therefore, any ltieral you pass will go through the pointer version rath= er than the array template.

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

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

Because the &= quot;lossy conversion" part being preferred has nothing to do with the= m being string literals. The lossy conversion is not the literal-to-array c= onversion; it's the array-to-pointer conversion.

You're comp= laining about the wrong problem.

This make it impossible to work= with string literal because they simply don't exist in the language. T= his is why I said string literals are broken.
=C2=A0
But there's no &= quot;fix" for this, since any array->pointer "fix" would = be both wildly incompatible with C and break 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"m_1712141763930148073prettyprint" style=3D"background-color:rg= b(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-widt= h:1px;word-wrap:break-word">
f(<= span style=3D"color:#000" class=3D"m_1712141763930148073styled-by-prettify"= >F"{a}{b}");

could translate to

f("&qu= ot;, a, ""<= span style=3D"color:#660" class=3D"m_1712141763930148073styled-by-prettify"= >, b, "");<= br>


arguments 0, ..., 2n a= re always literals and 1, ..., 2n-1 are always expressions.

<= /div>
f<= span style=3D"color:#660" class=3D"m_1712141763930148073styled-by-prettify"= >(F"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-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/c753= 942d-be11-4cc0-bde1-7f71b6184367%40isocpp.org.

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPrAspx= kZJXbhJyc9UCXS3FAw3UU0GEvAzURwKG1-pvoA%40mail.gmail.com.
--94eb2c04f868cc4418056521fdc6-- .