Boost logo

Boost :

Subject: Re: [boost] [contract] concept error messages
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2012-10-06 19:22:01

On Sat, Oct 6, 2012 at 11:29 AM, Andrew Sutton <asutton.list_at_[hidden]> wrote:
>> template< typename T >
>> typename std::enable_if<
>> AlwaysTrue<T>::value && contract::std::EqualityComparable<T>::value,
>> bool>::type equal1 ( T const& a, T const& b )
>> {
>> return a == b;
>> }
> Just curious, but what is the purpose of AlwaysTrue? If it's always
> true, why not omit it?

AlwaysTrue is there just so my example has 2 concepts instead of 1.
It's just for my own testing, you can ignore it.

>> And given this, I personally don't see the need for specifying
>> concepts in place of typename or using requires. In other words, I
>> think the above use of enable_if is sufficient and the following
>> syntax is not necessary (even if it's part of N3351):
>> template< AlwaysTrue T >
>> requires contract::std::EqualityComparable<T>
>> bool equal1 ( T const& a, T const& b )
>> {
>> return a == b;
>> }
> Lots of reasons, but mostly it clearly delineates what is required
> from what is returned.

But that's a limitation of enable_if for which we should provide
language support:

template< typename T >
bool equal ( ... ) if EqualityComparable<T>::value ;

And not a reason to support requires. Plus, I'd assume (all)
programmers will become rather familiar with enable_if syntax given
that it's in the std.

> >From a technical perspective, how would you specify this behavior for
> the standard? Can you do it in a way that guarantees the same behavior
> for all of the following, equivalent declarations?
> // std::enable_if
> template <typename T>
> typename std::enable_if<Eq<T>::value, bool>::type
> f(T x)
> // Boost enable_if
> template <typename T>
> typename boost::enable_if<Eq<T>, bool>::type
> f(T x)
> // Origin style
> template <typename T>
> Requires<Eq<T>(), bool>
> f(T x)
> Should the compiler know that all of these are the same?

Why should the compiler know that? I'm not following...

> How could you
> guarantee that? Would the behavior be different for the
> std::enable_if? If Requires was an alias to std::enable_if (it is),
> does that get the same behavior?
> Libraries are great for helping figure out what you want, but you're
> going to hit a wall at some point. I think "requires" is one of those
> walls.

I still don't understand... given that I can use enable_if (and
assuming I find its syntax clear enough), what's a use case that needs
requires instead?


Boost list run by bdawes at, gregod at, cpdaniel at, john at