Re: [boost] [contract] a possible future extension

Subject: Re: [boost] [contract] a possible future extension
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2012-08-28 14:31:30

Hi,

On Tue, Aug 28, 2012 at 12:27 AM, Andrzej Krzemienski
<akrzemi1_at_[hidden]> wrote:
> Hi Lorenzo,
> This is definitely outside the scope of the review, but I was wondering
> whether it would be feasible for the macros in Boost.Contract to handle
> base class aliases, as described in this proposal:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2881.html

Sure, this should be possible. I've entered a ticket for it:
https://sourceforge.net/apps/trac/contractpp/ticket/65

I'd propose the following syntax (given that these are essentially
typedefs), now in C++:

template< typename T, class CloneAlloc, class Alloc>
class ptr_vector
    : public ptr_sequence_adapter<T, std::vector<void*, Alloc>, CloneAlloc>
{
    typedef ptr_sequence_adapter<T, std::vector<void*, Alloc>, CloneAlloc>
            base_class;
    // base_class visible here (2)
    // ...
};

In N2881:

template< typename T, class CloneAlloc, class Alloc>
class ptr_vector
    : base_class = public ptr_sequence_adapter<T, std::vector<void*,
Alloc>, CloneAlloc>
    // base_class visible here (1)
{
    // base_class visible here (2)
    // ...
};

In a future Boost.Contract:

CONTRACT_CLASS(
    template< typename T, class CloneAlloc, class Alloc >
    class (ptr_vector)
        extends(
            typedef (public ptr_sequence_adapter<T, std::vector<void*, Alloc>,
                    CloneAlloc>) base_class
        )
    // maybe base_class visible here (1)...
) {
    // base_class visible here (2)
    // ...
};

This syntax is fully backward compatible with the current
Boost.Contract syntax. I don't know if I can make base_class visible
in the remaining base class list (1) (maybe I can... I'll have to see
when implementing this) but I can definitely make it visible in the
base class declaration (2) (as a typedef with the access level
suggested by N2881).

> The  positive "side effect" of your framework is that it has the potential
> to add various missing language features. I am wondering if these aliases

Yep, it's a "little" DSEL used to declare (not define) classes and
functions instead of the usual C++ declarations:
http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp_0_4_1/doc/html/contract__/grammar.html#contract__.grammar.preprocessor_dsel

Concept declarations could be added too (and use something like
Boost.Generic in the back-end, only I couldn't get my hands on
Boost.Generic source code :( ):
http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp_0_4_1/doc/html/contract__/concepts.html#contract__.concepts.concept_definitions__not_implemented_

The downside is that users need to learn the DSEL (even if it
resembles C++ syntax), bad preprocessor/compiler errors if you misuse
the syntax, and slow compilation times :( .

Thanks,
--Lorenzo