I've been looking at the C++1z N4377 Concepts TS draft that is being implemented in GCC 6, and I don't understand the purpose of having two different kinds of concepts: variable concepts and function concepts.
The relevant part of the draft for function concepts is [dcl.spec.concept (5.4)]
The declaration shall have a function-body equivalent to { return E; } where E is a constraint-expression (14.10.1.3).
and for variable concepts, in the next paragraph [(6.3)] :
The initializer shall be a constraint-expression.
Is there anything one of them can do, that the other cannot? If not, is there a rationale for including both?
Note: the latest draft, P0121R0 doesn't change anything in this regard
Function concepts can be overloaded on differing template parameter arity. Variable concepts provide nothing that function concepts don't, except for the ability to not put () in some contexts.
Eliminating variable concepts from the TS would not reduce the expressivity of concepts.
Related
I've been looking at the C++1z N4377 Concepts TS draft that is being implemented in GCC 6, and I don't understand the purpose of having two different kinds of concepts: variable concepts and function concepts.
The relevant part of the draft for function concepts is [dcl.spec.concept (5.4)]
The declaration shall have a function-body equivalent to { return E; } where E is a constraint-expression (14.10.1.3).
and for variable concepts, in the next paragraph [(6.3)] :
The initializer shall be a constraint-expression.
Is there anything one of them can do, that the other cannot? If not, is there a rationale for including both?
Note: the latest draft, P0121R0 doesn't change anything in this regard
Function concepts can be overloaded on differing template parameter arity. Variable concepts provide nothing that function concepts don't, except for the ability to not put () in some contexts.
Eliminating variable concepts from the TS would not reduce the expressivity of concepts.
Shouldn't std::invoke be constexpr especially after constexpr lambdas in C++17?
Are there any obstacles that will prevent this?
Update: P1065 will make it constexpr.
Keep original post for historical reason:
From the proposal:
Although there is possibility to implement standard conforming invoke function template as a constexpr function, the proposed wording does not require such implementation. The main reason is to left it consistent with existing standard function objects, that could have such definition, like std::mem_fn, std::reference_wrapper and operator wrappers. Furthermore imposing such requirement will block the implementation of invoke that refers to std::mem_fn.
This proposal assumes that constexpr addition to the header would be applied consistently by a separate proposal.
Both constexpr and standard library based implementation are presented in Implementability section of the proposal.
Related CWG issue #1581: When are constexpr member functions defined?.
The C++11 standard makes a couple of passing mentions to "function prototypes".
There are not in any definitions of the relevant features, but in random places like:
"function prototype scope" in [C++11: 3.3.4] (whose definition actually admits it's talking about "function declarations");
an editorial description of the library type definition clauses in [C++11: 17.5.1.4/1], footnote 175 (which seems to be referring to the C functionality);
[C++11: 20.9.4.3/6] which describes the hypothetical template <T> typename add_rvalue_reference<T>::type create(); as "a function prototype".
the same thing at [C++11: 20.9.6/4];
appendix [C++11: C.1.7] which talks about declarators in C: "The function declarations using C incomplete declaration style must be completed to become full prototype declarations, then later "Rationale: Prototypes are essential to type safety".
... and that's it.
Surely, we are set on the "declaration"/"definition" terminology and, since the C++ standard does not use the "prototype" terminology in its core definitions, these are merely typos/inconsistencies, introduced because some editors are familiar with C terminology?
Or is there some subtle meaning I'm missing?
Yes and no. I think some of the uses of "prototype" make sense, but others should really be changed to "declaration".
I agree that §3.3.4/1 should talk about "function declaration scope" instead of "function prototype scope".
§17.5.1.4 is talking about C++ headers, so I think it should probably use "declaration" instead of prototype.
Footnote 175 is specifically referring to what is provided by C headers, so there I think it's probably appropriate to use C terminology (i.e., to continue to use "prototype", though possibly with an added note that this is equivalent to a C++ declaration).
I'd agree that the use of "prototype" at §20.9.6/4 and §20.9.4.3/6 are both mistakes, and should use "declaration" instead.
C.1.7 is specifically comparing C to C++, talking about declarations vs. prototypes in C and how they compare to C++ declarations, so it nearly needs to retain the use of "prototype" to be meaningful.
As to a definition of "prototype" (or related features), ISO 9899:1999 (through TC 3) is a normative reference to the C++ standard, so its definition of "prototype" can be applied since the C++ standard itself provides none.
Draft C++14 has added support for variable templates. The examples in the proposal (N3651) all show constants (either constexpr or const), but, from what I can tell, this is not required. May variable template variables vary, e.g., be assigned to?
template<typename T>
T magicVal = 42;
magicVal<int> = 0; // okay?
Yes, variable template instances are first-class objects. Effectively a template-id is just a name.
"Under the hood" a variable template just the same as an old-fashioned class template with a single static member.
Edit: It seems that the proposal was written in terms of constexpr constants only, such as to generically represent mathematical entities. Extension to other objects was requested by the reviewing committee and added as an afterthought.
That would be a truly bizarre restriction; and reading through chapter 14 of the latest draft, there is no indication of anything of the kind.
Does the C++11 standard specify that the numeric_limits<T>::min and max have to be constant-expression that can be used in templates or static_assert?
More generally, how to find the list of the functions that are constant-expression according to the standard?
Indeed the standard (or my latest working draft) lists all members of std::numeric_limits in chapter 18.3.2.3 [numeric.limits] as constexpr (it won't do any good to actually quote those definitions here), for the general templated version as well as all the builtin specializations (18.3.2.7 [numeric.special]). So yes, they are guaranteed to be constant expressions (for conforming implementations that also actually support constexpr, of course).
As to your second, more general, question I cannot help you that much except just refer you to the C++ standard itself, whose latest draft, which doesn't really differ from the actual standard, is available for free. Or you might look at the more convenient but less binding cppreference.com.