There's an issue with this syntax: can concept definition itself be specialized? If so, then I don't see how this syntax support specialization. Function template can do full specialization at least, and constexpr variable template can do partial…
--
Zhihao
--
You received this message because you are subscribed to the Google Groups "SG8 - Concepts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to concepts+u...@isocpp.org.
To post to this group, send email to conc...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/concepts/.
There's an issue with this syntax: can concept definition itself be specialized? If so, then I don't see how this syntax support specialization. Function template can do full specialization at least, and constexpr variable template can do partial…
| However, currently it's possible to useFill that under 'implementation details of current concept lites' :-)
| constexpr bool functions as constraints, and those _can_ be specialized.
On Sun, Oct 27, 2013 at 9:40 AM, Ville VoutilainenVille, have you really tried to define a constexpr bool function
<ville.vo...@gmail.com> wrote:
> I have thought since the very first concepts lite proposal I saw that it
> would
> be fabulous if regular constexpr bool functions work as constraints.
as a concept/constrain, but still accept a function parameter
to do a different thing? I just don't see how a function instead
of a meta function can involve.
There is a difference between having "regular constexpr function"
usable in a constraint formulation and allowing concepts to be specialized.
The former does not require the latter, and the latter does not require
the former.
In the current specification of 'concepts lite', we only check uses of
templates on "ground types" or "ground values", e.g. when there is no
template parameter involved in the condition to evaluate. From that
perspective, we are "just" reusing the existing template instantiation
machinery but at a slightly "upper" level. That probably covers more
than half of the situations that people (end users) care about today.
Which is part of the reasons 'concepts lite' are so valuable.
If and when we want to check templates where the actual constraints
involve template parameters (e.g. template definitions), then not being
able to deduce the validity of a generic condition adds a source of
distinct difficulty, if not impossibility, to an already challending task.
Hi,
if a concept is always boolean function, isn't bool redundant?
|We don't evaluate the condition before values are provided for the
| In the current specification of 'concepts lite', we only check uses of
| templates on "ground types" or "ground values", e.g. when there is no
| template parameter involved in the condition to evaluate. From that
|
|
| I must misunderstand what you're saying here, because the template
| parameter of a constrained template seems to me to be used for
| the evaluation of the constraint, whether it's a concept or a constrant
| expression. It doesn't do lookup/instantiation of explicit concept
| specializations,
| though.
template parameters. With 'concepts lite', those values have to be
ground, e.g. 'int', 'vector<string>', '42, et'c. Those values are not
template parameters themselves, or do not involve template parameters.
Well, this is what it means to check template definitions :-)|
| We don't evaluate the condition before values are provided for the
| template parameters. With 'concepts lite', those values have to be
| ground, e.g. 'int', 'vector<string>', '42, et'c. Those values are not
| template parameters themselves, or do not involve template parameters.
|
|
| Ah, sure. I didn't even imagine reaching as far as having template parameters
| at the condition evaluation time, regardless of whether the constraint
| happens to be a template with possible specializations.
We already know that concept is unray type predicate, and it seems
that we have no interests, no plan to support concept specialization,
then what we leave the `typename` keyword here for?
concept Input_range<T> = requires(T range) {
typename Iterator_type<T>;Looks more clear to me, like a term-rewriting.
} && requires Input_iterator<T>;
> Why? Because we don't want concepts to have a wildly different syntaxThis thread starts with "a wildly different" syntax, so it appears that
> compared to existing facilities.
some people want.
> That eases the implementation, andAndrew says (to me, on cppnow) Concepts should be defined in a
> arguably eases the task for humans recognizing the syntactical patterns in
> the code,
> without having to switch gears when writing constrained code and concepts
> compared to writing 'regular' code.
centralized place per project. If that's true, then you may not have
a chance to "switch gears" between looking at constrain definition
and concepts definition.
> I'm not talking about concepts vs. constraints. I'm talking aboutThen what you may want to care about is what a constrained
> unconstrained
> existing code and constrained new code. I prefer having a minimized
> difference
> between them.
declaration looks like (like Bjarne said, concept-name in place of
`typename`). Concept definition is new, as well as
_requires-expression_. So I'm fine if concept definition looks
"wildly different" (since _requires-expression_ is wild enough :)
While subseting an existing syntax may make the language
harder to learn, teach, and use. When I say "subseting" I mean:
N3701 7.1.7:
Concept definitions have the following restrictions:
- The template must be unconstrained.
- The result type must be bool.
- The declaration may have no function parameters.
- The declaration must be defined.
- The function shall not be recursive.
After constexpr function is being relaxed, you will need to
exclude more rules here, pretty much by reverting N3652.
I think with this restriction provided it is better and less suprising
to model the concepts (not constraints) as a template variable
in a form:
template<typename T>
concept bool C<T> = requires ...;
Using the variable syntax already imposes the two restrictions that
are not so intuitive for the constexpr functions used as concepts:
no parameters allowed and allowance of only one statement that is return,
which was removed from the lastest standard for constexpr functions.
So I your are not planning to allow concepts (not constraint) with
parameters in further revisions, I think it would be better to allow
only variable syntax for concepts, because the restrictions of
concepts that are imposed for the constexpr functions will no longer
be needed, expect the one about specializations.
Also I think it will make the possible future syntax for any "full" concepts
more coherent as we will have:
template<typename T>
concept bool C<T> { requires ... };
And eventually:
template<typename T>
concept class C<T> { requires ... };
On 10/28/2013 4:00 PM, toma...@gmail.com wrote:
It seems to me that you are (all) trying to make concepts values/objects. They are predicates.