similar to: RFC: Constructing StringRefs at compile time

On Mon, Nov 28, 2016 at 11:01 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > On Nov 28, 2016, at 9:47 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > OK - good to know. (not sure we're talking about pessimizing it - just not > adding a new/possible optimization, to be clear) > > > This does not seem that clear to me. The

On 29 November 2016 at 16:18, Zachary Turner <zturner at google.com> wrote: > I don't like the llvm_strlen approach as it is incompatible with > std::string_view which we may eventually move to. In what way is it incompatible? constexpr StringRef(const char* s) : Data(s), Length(llvm_strlen(s)) {} is equivalent to constexpr string_view(const char* s) : Data(s),

On 24 November 2016 at 15:04, Hal Finkel <hfinkel at anl.gov> wrote: >> Creating constexpr StringRefs isn't trivial as strlen isn't portably >> constexpr and std::char_traits<char>::length is only constexpr in >> C++17. > > Why don't we just create our own traits class that has a constexpr length, and then we can switch over to the standard one when

The fact that the templatized constructor falls down because of the possibility of initializing StringRef with a stack-allocated char array kills that idea in my mind. I feel like the only two reasonable solutions are 1) allow UDL for this case, document that this is an exception and that UDLs are still not permitted anywhere else, and require (by policy, since I don't know of a way to have

On 29 November 2016 at 17:38, Zachary Turner <zturner at google.com> wrote: > I see, but I looked over your proposed implementation from earlier in the > thread, and if I'm not mistaken I see this: That's a different suggestion. > That said, what did you think about my other proposal of the complicated UDL > with macro? > > #define LIT(x) x_string_ref_literal >

On 28 November 2016 at 20:51, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > The basic idea here is that you introduce a StringLiteral class and anywhere > you want to use a global constructor, you make sure to declare a constexpr > array instead of a normal array, and you make it of type StringLiteral. I prefer constexpr llvm_strlen() over StringLiteral because

On 28 November 2016 at 19:30, Mehdi Amini <mehdi.amini at apple.com> wrote: > This thread started with: "There is a desire to be able to create constexpr > StringRefs to avoid static initializers for global tables of/containing > StringRefs.” > > I don’t have more information, but maybe Malcolm can elaborate? I was restating your motivation from

On Fri, Nov 25, 2016 at 6:10 AM Mueller-Roemer, Johannes Sebastian via llvm-dev <llvm-dev at lists.llvm.org> wrote: > What about going for > > template<unsigned N> > constexpr StringRef(const char (&Str)[N]) > > and avoiding strlen entirely for string literals? > You'd at least want an assert in there (that N - 1 == strlen(Str)) in case a StringRef is

OK - good to know. (not sure we're talking about pessimizing it - just not adding a new/possible optimization, to be clear) Just out of curiosity - are there particular reasons you prefer or need to ship an MSVC built version, rather than a bootstrapped Clang? On Mon, Nov 28, 2016 at 9:24 AM Robinson, Paul <paul.robinson at sony.com> wrote: > So I wouldn't personally worry too

char buffer[100]; And it also allows LIT(buffer) to compile, whereas the UDL doesn't. On Tue, Nov 29, 2016 at 9:54 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Nov 29, 2016, at 9:52 AM, Malcolm Parsons <malcolm.parsons at gmail.com> > wrote: > > > > On 29 November 2016 at 17:38, Zachary Turner <zturner at google.com> wrote: > >>

Well, apparently clang has clang::StringLiteral in clang/AST/Expr.h So, our options are either: Allow this name clash (obviously the namespaces don't clash, only the names) and deal with it when it's an issue (which will be limited to clang, and even then not very often), or choose a different name. Thoughts? On Mon, Dec 12, 2016 at 11:53 AM Zachary Turner <zturner at google.com>

I can. I'll whip something up today On Fri, Dec 9, 2016 at 1:18 AM Malcolm Parsons <malcolm.parsons at gmail.com> wrote: > On 2 December 2016 at 17:12, James Y Knight <jyknight at google.com> wrote: > > +1 from me for the StringLiteral proposal from a few messages back. > > Zachary, do you want to commit StringLiteral? > > -- > Malcolm Parsons >

On Mon, Dec 12, 2016 at 1:03 PM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Well, apparently clang has clang::StringLiteral in clang/AST/Expr.h > > So, our options are either: Allow this name clash (obviously the > namespaces don't clash, only the names) and deal with it when it's an issue > (which will be limited to clang, and even then not

On 2 December 2016 at 17:12, James Y Knight <jyknight at google.com> wrote: > +1 from me for the StringLiteral proposal from a few messages back. Zachary, do you want to commit StringLiteral? -- Malcolm Parsons

> On Dec 12, 2016, at 3:45 PM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Mon, Dec 12, 2016 at 1:03 PM Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Well, apparently clang has clang::StringLiteral in clang/AST/Expr.h > > So, our options are either: Allow this name

On Mon, Oct 31, 2016 at 3:46 PM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > Tentatively final version is up here: https://reviews.llvm.org/D25587 > > It has a verbal LGTM, but I plan to wait a bit longer just in case anyone > has some additional thoughts. It's a large patch, but if you're > interested, one way you can help

Ahh, I must have missed where you voiced that objection earlier. Do you prefer that UDL syntax be explicitly disallowed, or do you only prefer that normal c++ syntax be possible? It is currently possible, I just didn't demonstrate it in the previous message since almost all the feedback i had seen so far seemed to prefer UDL syntax due to the brevity and similarity to Python. I recall you

On Mon, Oct 31, 2016 at 5:21 PM, Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Oct 31, 2016 at 3:46 PM Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> Tentatively final version is up here: https://reviews.llvm.org/D25587 >> >> It has a verbal LGTM, but I plan to wait a bit

You get compile time checking automatically when we can use c++14 though. If you use it with a string literal, you'll get compile time checking, otherwise you won't. Here's a different example though. Suppose you're writing a tool which prints formatted output, and the field width is specified by the user. Now you NEED to build the format string at runtime, there's no other

* UDL Syntax is removed in the latest version of the patch <https://reviews.llvm.org/D25587>. * Name changed to `formatv` since `format_string` is too much to type. * Added conversion operators for `std::string` and `llvm::SmallString`. I had some feedback offline (not on this thread, unfortunately) that it might be worth using a printf style syntax instead of this Python-esque syntax.