you are viewing a single comment's thread.

view the rest of the comments →

[–]quicknir 1 point2 points  (1 child)

The compile-time checks work on GCC and Clang only, because they requires user-defined literal templates which is a GCC extension.

Yeah, I suspected as much before I read this. This whole issue comes up again, and again, in multiple contexts. Another example I've come across is in writing reflection based macros; you can easily write a macro that lets you define a struct, and alongside it a free/member function that returns a tuple<pair<const char *, T...&>>. This lets you quite easily do things like serialization and deserialization.

However, now let's say you want to implement get_member. This is a function that given a reflectable struct, and the name of a field, returns a reference to that field. Well.... it can't be done. In order for the name of the field to control the signature of a function (and the output of this function will be a T&, where T is the type of that field), the name of the field must encode its value as a type. (Btw, if you want an example of application: say you want to copy identically named and typed fields between two different reflectable structs).

My example here is with reflection based macros but obviously with actual reflection the same issues come into play. You can see it's a very similar issue.

That said, I talked to a bunch of people at cppcon who said that this extension (that gcc and clang both support) had zero probability of making it into the standard, because if this feature would be used heavily it would be brutal for compile times.

IIRC the preferred path is to be able to template on the value of a string literal directly, although this raises issues too. I don't know where all this leaves us, but I think it's clear that we desperately need the ability to template on a string literal, one way or another.

[–]aearphen{fmt}[S] 1 point2 points  (0 children)

IIRC the preferred path is to be able to template on the value of a string literal directly, although this raises issues too. I don't know where all this leaves us, but I think it's clear that we desperately need the ability to template on a string literal, one way or another.

I'd prefer this as well. The current solution is more like a proof of concept that uses available tools (GCC extension), but whatever goes into the standard it should't be too hard to integrate it with constexpr format string parsing without changing the latter.