[P0424] Reconsidering literal operator templates for strings

[Louis Dionne]

Dear list,

In 2013, N3599 tried adding literal operator templates for strings:

  template <typename CharT, ChartT ...c>

  auto operator"" _user_defined_literal();

Unfortunately, the paper was rejected at the time on the basis of lacking proper

machinery for compile-time string processing. Motivated by several use cases

requiring this literal operator (but no additional string processing machinery),

I wrote a paper to try and revive this discussion with the committee.

The latest draft of this paper is at [1]; please let me know of any comments.

Regards,

Louis Dionne

[1]: http://htmlpreview.github.io/?https://github.com/ldionne/wg21/blob/master/generated/P0424R0.html

[Arthur O'Dwyer]

On Sunday, August 14, 2016 at 1:11:31 PM UTC-7, Louis Dionne wrote:

In 2013, N3599 tried adding literal operator templates for strings:

  template <typename CharT, ChartT ...c>

  auto operator"" _user_defined_literal();

Unfortunately, the paper was rejected at the time on the basis of lacking proper

machinery for compile-time string processing. Motivated by several use cases

requiring this literal operator (but no additional string processing machinery),

I wrote a paper to try and revive this discussion with the committee.

The latest draft of this paper is at [1]; please let me know of any comments.

[1]: http://htmlpreview.github.io/?https://github.com/ldionne/wg21/blob/master/generated/P0424R0.html

I'm wholly in favor of this idea, and the paper looks great.  I would love to see this in '17, even though I suspect it's missed the boat.

In C++17, I wonder whether the idea of template<typename CharT, CharT... ch> operator""_udl is obsolete or archaic already. What if I've provided a template<auto... ch> operator""_udl, is that good enough?  (Obvious literal answer: "no." But is there a good reason it shouldn't be? Bonus points if the good reason is something other than "compatibility/consistency with the C++11 version.")

Today I learned about htmlpreview.github.io, and it seems neat, but FYI, it breaks your link to http://cplusplus.github.io/EWG/ewg-active.html#66 by turning it into a link to https://htmlpreview.github.io/?https://github.com/ldionne/wg21/blob/master/generated/P0424R0.html#66 .  Therefore you would do better to "publish" this draft by adding it to your gh-pages branch instead.

(The htmlpreview bug is already filed: #43.)

my $.02,

–Arthur

[Louis Dionne]

On Sunday, 14 August 2016 22:22:16 UTC-7, Arthur O'Dwyer wrote:

On Sunday, August 14, 2016 at 1:11:31 PM UTC-7, Louis Dionne wrote:

In 2013, N3599 tried adding literal operator templates for strings:

  template <typename CharT, ChartT ...c>

  auto operator"" _user_defined_literal();

Unfortunately, the paper was rejected at the time on the basis of lacking proper

machinery for compile-time string processing. Motivated by several use cases

requiring this literal operator (but no additional string processing machinery),

I wrote a paper to try and revive this discussion with the committee.

The latest draft of this paper is at [1]; please let me know of any comments.

[1]: http://htmlpreview.github.io/?https://github.com/ldionne/wg21/blob/master/generated/P0424R0.html

I'm wholly in favor of this idea, and the paper looks great.  I would love to see this in '17, even though I suspect it's missed the boat.

I'm targeting C++20. 

 

In C++17, I wonder whether the idea of template<typename CharT, CharT... ch> operator""_udl is obsolete or archaic already. What if I've provided a template<auto... ch> operator""_udl, is that good enough?  (Obvious literal answer: "no." But is there a good reason it shouldn't be? Bonus points if the good reason is something other than "compatibility/consistency with the C++11 version.")

I assume this could be made to work, but it might be slightly difficult to get the `CharT` type from just the `auto` parameter pack. We'd have to write a helper metafunction such as

  template <auto c, auto ...cs>

  struct type_of_first { using type = decltype(c); };

Also, in case the parameter pack is empty (""_udl), we'd have no way to figure that type out.

 

Today I learned about htmlpreview.github.io, and it seems neat, but FYI, it breaks your link to http://cplusplus.github.io/EWG/ewg-active.html#66 by turning it into a link to https://htmlpreview.github.io/?https://github.com/ldionne/wg21/blob/master/generated/P0424R0.html#66 .  Therefore you would do better to "publish" this draft by adding it to your gh-pages branch instead.

(The htmlpreview bug is already filed: #43.)

Thanks a lot. In any case, I rewrote the proposal in Latex due to other feedback I received. You can find it attached.

 

Regards,

Louis

[Richard Smith]

On Mon, Aug 15, 2016 at 10:09 AM, Louis Dionne <ldio...@gmail.com> wrote:

On Sunday, 14 August 2016 22:22:16 UTC-7, Arthur O'Dwyer wrote:

On Sunday, August 14, 2016 at 1:11:31 PM UTC-7, Louis Dionne wrote:

In 2013, N3599 tried adding literal operator templates for strings:

  template <typename CharT, ChartT ...c>

  auto operator"" _user_defined_literal();

Unfortunately, the paper was rejected at the time on the basis of lacking proper

machinery for compile-time string processing. Motivated by several use cases

requiring this literal operator (but no additional string processing machinery),

I wrote a paper to try and revive this discussion with the committee.

The latest draft of this paper is at [1]; please let me know of any comments.

[1]: http://htmlpreview.github.io/?https://github.com/ldionne/wg21/blob/master/generated/P0424R0.html

I'm wholly in favor of this idea, and the paper looks great.  I would love to see this in '17, even though I suspect it's missed the boat.

I'm targeting C++20.

You have my support :)

In C++17, I wonder whether the idea of template<typename CharT, CharT... ch> operator""_udl is obsolete or archaic already. What if I've provided a template<auto... ch> operator""_udl, is that good enough?  (Obvious literal answer: "no." But is there a good reason it shouldn't be? Bonus points if the good reason is something other than "compatibility/consistency with the C++11 version.")

I assume this could be made to work, but it might be slightly difficult to get the `CharT` type from just the `auto` parameter pack. We'd have to write a helper metafunction such as

  template <auto c, auto ...cs>

  struct type_of_first { using type = decltype(c); };

Also, in case the parameter pack is empty (""_udl), we'd have no way to figure that type out.

 

Today I learned about htmlpreview.github.io, and it seems neat, but FYI, it breaks your link to http://cplusplus.github.io/EWG/ewg-active.html#66 by turning it into a link to https://htmlpreview.github.io/?https://github.com/ldionne/wg21/blob/master/generated/P0424R0.html#66 .  Therefore you would do better to "publish" this draft by adding it to your gh-pages branch instead.

(The htmlpreview bug is already filed: #43.)

Thanks a lot. In any case, I rewrote the proposal in Latex due to other feedback I received. You can find it attached.

 

Regards,

Louis

--
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/67df98ef-c02d-484e-ac52-6a92c1b18778%40isocpp.org.

[Larry Evans]

On 08/15/2016 12:09 PM, Louis Dionne wrote:
>
>
> On Sunday, 14 August 2016 22:22:16 UTC-7, Arthur O'Dwyer wrote:
>
> On Sunday, August 14, 2016 at 1:11:31 PM UTC-7, Louis Dionne wrote:
>
>
> In 2013, N3599 tried adding literal operator templates for strings:
>
> template <typename CharT, ChartT ...c>
> auto operator"" _user_defined_literal();
>
> Unfortunately, the paper was rejected at the time on the basis
> of lacking proper
> machinery for compile-time string processing. Motivated by
> several use cases
> requiring this literal operator (but no additional string
> processing machinery),
> I wrote a paper to try and revive this discussion with the
> committee.
>
> The latest draft of this paper is at [1]; please let me know of
> any comments.
> [1]:
> http://htmlpreview.github.io/?https://github.com/ldionne/wg21/blob/master/generated/P0424R0.html

> <http://htmlpreview.github.io/?https://github.com/ldionne/wg21/blob/master/generated/P0424R0.html>
>
Apparently that's been removed since I couldn't find it a few moments ago.
[snip]

> Thanks a lot. In any case, I rewrote the proposal in Latex due to other
> feedback I received. You can find it attached.
>
> Regards,
> Louis

Thanks Louis.

Not being familiar with literal operator's, it took me a while to
understand the create_window code. To help me, I modified the
code as shown in the gist:

https://gist.github.com/cppljevans/555ba34134a82c8a524d8c42702c9d28

As indicated in the //Modifications comment, several print statements
were added to illustrate the workings.

Hopefully others will find it helpful in understanding the code.

-regards,
Larry

[3dw...@verizon.net]

As the implementer for this in gcc I thank you for this.

The only potential issue I can think of is that u8 is now a valid character literal prefix.  Some allowance for that might need to be made in the wording.

Ed

[3dw...@verizon.net]

Changing the sentence fragment in [lex.ext] (2.14.8)/5:
 ... where e is empty when the encoding-prefix is u8 and is otherwise the encoding-prefix of the string literal,
to
 ... where e is the encoding-prefix of the string literal,
should do it.

Ed

[D. B.]

FYI the generated PDF now lives at
https://github.com/ldionne/wg21/blob/master/generated/D0424R0.pdf

with sources available in the parent directory.

[Louis Dionne]

Thanks a lot! I updated the paper with this new change.

You can find it attached or at https://github.com/ldionne/wg21/blob/master/generated/D0424R0.pdf.

Regards,

Louis Dionne

[Tom Honermann]

On 8/21/2016 6:27 PM, Louis Dionne wrote:

You can find it attached or at https://github.com/ldionne/wg21/blob/master/generated/D0424R0.pdf.

I'm also in favor of this proposal.  The lack of such facilities is also discussed in P0244R1 in the Future Directions/Constexpr Support section [1] should you like to reference it in your proposal.

Tom.

[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0244r1.html#future_constexpr

[smili...@googlemail.com]

AFAIUI, one would then create a compile-time string wrapper, e.g. fixed_string (P0259R0), from the UDL-operator for any further processing.

There has also been the idea floating around of making regular string literals more amenable to compile-time computations, e.g. allowing them as template parameters, by implicitly converting them to (e.g) a fixed_string (or: like an initializer_list, that is magically constructed by the compiler). This would have the benefit of not having to "tag" (i.e. add _udl) any string (or any macros to hide the taggging...).

Therefore I'd be grateful for some clarification, whether the proposal should be considered in addition or instead of any future extensions in regular string literal handling. Do you believe that the presented approach is actually better (or actually worse), than upgrading regular string literals (which, AFAIK, hasn't been implemented anywhere yet)?

  Tobias

[Louis Dionne]

On Sunday, 28 August 2016 11:17:35 UTC-7, smili...@googlemail.com wrote:

On Sunday, August 14, 2016 at 10:11:31 PM UTC+2, Louis Dionne wrote:

Dear list,

In 2013, N3599 tried adding literal operator templates for strings:

  template <typename CharT, ChartT ...c>

  auto operator"" _user_defined_literal();

Unfortunately, the paper was rejected at the time on the basis of lacking proper

machinery for compile-time string processing. Motivated by several use cases

requiring this literal operator (but no additional string processing machinery),

I wrote a paper to try and revive this discussion with the committee.

The latest draft of this paper is at [1]; please let me know of any comments.

Regards,

Louis Dionne

[1]: http://htmlpreview.github.io/?https://github.com/ldionne/wg21/blob/master/generated/P0424R0.html

AFAIUI, one would then create a compile-time string wrapper, e.g. fixed_string (P0259R0), from the UDL-operator for any further processing.

Possibly, but not necessarily. If you look at my proposal, the named argument use case is not something that you can do with something like

`fixed_string` proposed in P0259R0. To implement something like named arguments, you need the _contents_ of the string to be encoded in

the type of whatever you use to represent the string, not only its size. One author of P0259R0 seem to have missed this, which lead him to

a plainly wrong conclusion in a previous paper (N4121):

    First, to properly frame the discussion, we would like to demonstrate that you can form a std::string_literal<n> from such a char pack, and

    then we will show how to do the opposite, convert a std::string_literal<n> to a char pack.

Instead, what they prove is that a `constexpr std::string_literal<n>` is equivalent to a `char` pack. Unfortunately, a `constexpr std::string_literal<N>`

is not something that we often get to manipulate. For example, passing a `constexpr std::string_literal` as an argument to a function, even if the

function is marked as `constexpr`, will decay the constexpr-ness of the `string_literal`.

In other words, a string whose content is encoded in its type is strictly more powerful than the proposed fixed_string, and sometimes you need

that additional power (such as in the named argument example). Other times, a fixed_string might be enough, but I can't think of any use cases

where a string_view would not be enough right now. In such cases where the full type-encoded string can be avoided, then it probably should be

avoided for compilation time reasons (although constexpr is sometimes slower than template instantiation, so I'd like to see measurements before

anything is standardized).

There has also been the idea floating around of making regular string literals more amenable to compile-time computations, e.g. allowing them as template parameters, by implicitly converting them to (e.g) a fixed_string (or: like an initializer_list, that is magically constructed by the compiler). This would have the benefit of not having to "tag" (i.e. add _udl) any string (or any macros to hide the taggging...).

If we were able to get regular string literals as _template arguments_, then I think that would technically remove the need for the user-defined literal I'm proposing.

And by technically, I mean that there would be a way to achieve the same results as with the proposed literal in standard C++, but the syntax would still be quite

different. For example, you could obviously not write `"x"_arg = 3` as in my proposal, but instead you'd write something like `arg<"abc"> = 3`. It might make sense

for named arguments, but I can imagine other contexts where the user-defined literal is desirable.

 

Therefore I'd be grateful for some clarification, whether the proposal should be considered in addition or instead of any future extensions in regular string literal handling. Do you believe that the presented approach is actually better (or actually worse), than upgrading regular string literals (which, AFAIK, hasn't been implemented anywhere yet)?

As I suggest it above, I believe this proposal should be considered _in addition_ of any future extension to the handling of regular string literals.

I have nothing against being able to say `foo<"xyz">`, and in fact I believe it would be very useful. However, being able to say `foo<"xyz">` is not

a replacement for my proposal.

Regards,

Louis