Re: [boost] [Review.Contract] Vicente's review

Subject: Re: [boost] [Review.Contract] Vicente's review
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2012-09-04 04:03:57

2012/9/4 Lorenzo Caminiti <lorcaminiti_at_[hidden]>

> On Sun, Sep 2, 2012 at 11:14 PM, Vicente J. Botet Escriba
> <vicente.botet_at_[hidden]> wrote:
> > 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_at_[hidden]> 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
> 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?

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.

Regards,
&rzej