Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns

Subject: Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2012-10-13 08:28:37

2012/10/12 Dave Abrahams <dave_at_[hidden]>

>
> on Fri Oct 12 2012, Andrew Sutton <asutton.list-AT-gmail.com> wrote:
>
> >>> If I remember correctly, we assumed that a conversion requirement on
> >>> the result of an operation, would actually convert (if necessary).
> >>
> >> What does "if necessary" mean?  I can think of at least two different
> >> ways to decide whether a conversion is necessary.
> >
> > If the expression returns bool, no conversion is necessary. If it does
> > not, then a conversion is needed.
>
> Sorry, that's still too vague to tell me what you mean.  Surely this has
> nothing to do with "bool-ness," so I have to assume bool shows up in an
> example you have in mind.  Could you show a concrete example with
> specific requirements?
>

Pardon me, if I completely misunderstood your concern. This is how I
understand the issue you describe:

We have a concept requirement like this:

concept Operation<typename Op, typename T>
= requires(Op op, T t)
{
  //...
  bool = { op(t) }; // "convertible to bool"
}

We have the following function template

template< typename Op, typename T >
requires Operation<Op, T>
bool fun(Op op, T t) {
  return true && op(t);
}

We have a following concrete type that models Operation:

class FunnyBool{...}; // almost like bool
class X{...}; // which will become T
FunnyBool operation(X x) {...}; // which will become Op
bool operator&& (bool a, FunnyBool b) {}; // which will do some unexpected
thing

When we instantiate:

fun(operation, X{});

which operator&& will be picked? (bool, bool) or (bool, FunnyBool)?

This is the question you ask. Am I right?
If so, the answer I find the most logical would be is since the concept is
only aware that the type is convertible to bool and can only rely on this
information, when function fun() is instantiated with operation and X, it
only sees a restricted version of operation and X and indirectly FunnyBool
as though  'through concept Operation' and must convert FunnyBool to bool
before applying operator &&.

Of course this is achievable only in concepts as language feature. Any
use-pattern-based concept library will not be able to implement this
behavior, as far as I am aware.

Regards,
&rzej