On Tue, Sep 4, 2012 at 1:03 AM, Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
2012/9/4 Lorenzo Caminiti <lorcaminiti@gmail.com>
Le 03/09/12 00:14, Lorenzo Caminiti a écrit :
On Sun, Sep 2, 2012 at 2:39 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Hi,
here is my short review.
My vote is YES subject to these condition.
Thanks a lot for the review.
* Removal of the Concepts part. The use of Boost.ConceptCheck to emulate C++ concepts proposal is in my opinion erroneous. Boost.Concept.Check is used to assert the actual parameter satisfy statically the concept conditions, while if I'm not wrong the C++ Concepts proposal use the requires clause to state the conditions of a possible instantiations. Using the same grammar with different semantics is confusing. In a last resort, if this feature is preserved, the requires keyword must be changed by another one.
If that were to be the final decision, I'll remove the interface to Boost.ConceptCheck or I can use any (alphanumeric) mane rather than requires (e.g., where).
However, I can use the requires clausule to do multiple things: 1. Check concepts defined using Boost.ConceptCheck (current, I'd leave it as is). 2. Check static_assert (under consideration, to be moved here from within pre/post/inv). 3. Check Boost.Generic-like concepts implemented using C++11 expression SFINAE (for future... this will be *a lot* of work...). I should be able to support of all those because I can distinguish 2 using the pp (starts with static_assert)
I will really prefer the static_assert goes outside requires, e.g. in a new *check* clause. This clause could also contain the ConceptCheck part. In this way it is clear that the requires part will disable the instantiation if not satisfied, and the check part will report a compile-time error if not satisfied.
and I can distinguish between 1 and 2 using the compiler for example using a (hidden) tagging base class to all concepts defined for 3.
I'm not sure this distinction is possible. For function templates, the requires part associated to ConceptCheck should be included in the function definition, while the one associated to enable_if/SFINAE c++ proposal concepts emulation should be part of the C++ declaration. For template classes, ConceptCheck goes to the members part, while Concepts goes to
On Sun, Sep 2, 2012 at 11:14 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote: the
template parameter part.
As you can see the semantics are different, so a specific keyword would help to identify the difference.
Can you provide an example of how all of this would ideally look like? You can also pick a "keyword" other than requires that makes sense to you and then indicate where to use requires and where to use the other keyword in the example. Maybe you start from the static_assert example I gave:
template< typename To, typename From > requires // new concepts?? Convertible<From, To> // disable this declaration using SFINAE?? unless // static_assert and Boost.ConceptCheck?? static_assert(sizeof(To) >= sizeof(From), "destination too small"), // generate compiler-error?? boost::Copyable<From> // generate compiler-error?? To* memcopy ( To* to, From* from ) precondition { to; // pointer not null from; // pointer not null } { // ... }
Or any other example will do but I want to fully understand what your idea is. Thanks :)
Oh, I did not realize that Boost.ConceptCheck does not use SFINAE-based techniques. In that case, given that you only check constraints and do not have SFINAE-based concepts, the ideal syntax (macro-free) would be something like:
template< typename To, typename From > static_assert(sizeof(To) >= sizeof(From), "dest too small"), static assert(Copyable<From>, "2nd arg not copyable") To* memcopy ( To* to, From* from ) precondition { to != nullptr; from != nullptr; } { // ... }
Although, it may not be achievable with current Boost.ConceptCheck because Copyable<From> is not a predicate; or is it?
No, it's not :( My understand is that the set of conditions for with you can program predicates is smaller than the one for which you can generate a compiler error in C++.
On the other hand, I am not sure how much value it adds over putting static asserts inside function body. In C++ in case of templates we are forced and used to provide definitions along declarations.
Thanks. --Lorenzo