Template literal operator for string literals

[dobr...@gmail.com]

My proposal / idea is about possible literal operator definitions.

Given a literal operator for integers, e.g. 

Weight w1 = 15_kg;

You can write a literal operator for this in ways:

constexpr Weight operator""_kg(unsigned long long q) {

    return Weight{q};

}

Weight operator""_kg(const char * str) {

    // ...

}

template<char... CHARS>

constexpr Weight operator""_kg() {

    // ...

}

The second one and the third one differs by one important thing: 3rd allows us to process integer literals by individual characters in compile time. If you write

0x7b_kg

Then you get '0', 'x', '7', 'b' characters as you expect.

But if you want to write a literal operator for a string literal, you have only one option:

std::string operator""_x(const char * str, std::size_t len) {

    // ...

}

Which is quite illogical. We have the option for integer literals to parse them as either template<char...> or const char*, but we are denied to be able to parse strings at compile time... 

I propose there should be an option like this for string literals as well.

template<char... CHARS, std::size_t LEN>

std::string operator""x() {

    // ...

}

or maybe

template<char... CHARS>

std::string operator""x(std::size_t len) {

    // ...

}

Obviously, the final goal is to have something like this, without having to specify the characters individually, initialized with a beautiful string literal and a helper literal operator.

template<char... CHARS>

struct constexpr_str

{

    static constexpr char const value[] = {CHARS..., '\0'};

};

What do you think?

[Chris DeVisser]

Your best bet here would be to support P0424, where Louis Dionne has argued for this. If you want to use this today, GCC and Clang have implemented it as an extension.

--
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-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/34f510eb-9b14-4e5f-9485-761f71476eaf%40isocpp.org.

[dobr...@gmail.com]

Thanks, this is what I'm looking for, didn't know this existed. :)

Do you think this is going to get into standard someday? I hate using nonstandard extensions, but soon-to-be-standard solutions are acceptable for me.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

[Chris DeVisser]

I think it's a reasonable addition, but I have not heard anything about the paper beyond the proposal, so it's hard to say how it will do. It certainly won't be in C++17 if that's what you were hoping for, but I'd say it has a shot at C++20.

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-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f1dca69-760e-49e3-8346-942c67abcf46%40isocpp.org.

[dobr...@gmail.com]

I knew new features of C++17 have been fixed, so I was not hoping for that. It would be awesome if we had this, thank you for your answers.

How can I use this in GCC / Clang?

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f1dca69-760e-49e3-8346-942c67abcf46%40isocpp.org.

[Louis Dionne]

I presented that paper in front of the Evolution Working Group last Tuesday. Compiler implementers in the room said that

they wanted to see a different way of having compile-time strings in the language, for compile-time performance reasons.

Same old story as when this idea was presented before, in other words. We're currently looking into alternatives such as

arrays as non-type template arguments, but we're hitting some issues.

Louis

[Chris DeVisser]

Thanks for sharing, Louis. It's a shame to see this feature missing, but it's good to see work on compile-time strings.

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-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/170d2f3b-5249-4c4d-908b-0a259e1b0c51%40isocpp.org.

[D. B.]

Regarding earlier discussion - is the feature set of C++17 totally fixed now, or is it still subject to late national body comments?

[Louis Dionne]

> On Nov 13, 2016, at 02:06, D. B. <db0...@gmail.com> wrote:
>
> Regarding earlier discussion - is the feature set of C++17 totally fixed now, or is it still subject to late national body comments?

My understanding is that the feature set is fixed now (and has been since Oulu at least).
We went through most of the NB comments in Issaquah, but those are not really new “features”,
they’re more like bug fixes AFAIU.

Louis

[Nicol Bolas]

To be fair, some of those NB comments were genuine feature requests, like "add concepts/operator-dot/etc to the standard". I know Herb Sutter at least thought that operator-dot might be able to get in via an NB comment.

[Tony V E]

Non of the feature requests were excepted. At least not anything major.

Sent from my BlackBerry portable Babbage Device

From: Nicol Bolas Sent: Sunday, November 13, 2016 7:03 PM To: ISO C++ Standard - Future Proposals Reply To: std-pr...@isocpp.org Subject: Re: [std-proposals] Template literal operator for string literals

--
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/aab343a1-92ca-4f0b-83cd-b306b31477e1%40isocpp.org.