On 20.11.2011 21:07, Andrei Alexandrescu wrote:
> On 11/20/11 10:41 AM, Norbert Nemec wrote:
> [snip]
>
> Why not follow the patter of isXxx in the standard library?
>
> Andrei

Actually, that was my starting point. However, this approach does not scale up:

A concept typically is a collection of requirements that have to be met individually. A huge boolean statement inside an assertion does not give any clue as to which part of it failed.

The isXxx approach works fine for the template constraint itself, but to assert that a given type meets all requirements of a concept, it is not very usable at all.

> Actually, that was my starting point. However, this approach does not scale up:
> 
> A concept typically is a collection of requirements that have to be met individually. A huge boolean statement inside an assertion does not give any clue as to which part of it failed.
> 
> The isXxx approach works fine for the template constraint itself, but to assert that a given type meets all requirements of a concept, it is not very usable at all.

Wouldn't it be preferable to improve the compiler to a degree, that it can tell, which subexpression of a constraint failed?

Norbert Nemec Wrote:

> On 20.11.2011 21:07, Andrei Alexandrescu wrote:
> > On 11/20/11 10:41 AM, Norbert Nemec wrote:
> > [snip]
> >
> > Why not follow the patter of isXxx in the standard library?
> >
> > Andrei
> 
> Actually, that was my starting point. However, this approach does not scale up:
> 
> A concept typically is a collection of requirements that have to be met individually. A huge boolean statement inside an assertion does not give any clue as to which part of it failed.
> 
> The isXxx approach works fine for the template constraint itself, but to assert that a given type meets all requirements of a concept, it is not very usable at all.

If an assertion fails do you want the compiler to terminate or to silently proceed to the next overload?

On 21.11.2011 09:24, Tobias Pankrath wrote:
>> Actually, that was my starting point. However, this approach does not
>> scale up:
>>
>> A concept typically is a collection of requirements that have to be met
>> individually. A huge boolean statement inside an assertion does not give
>> any clue as to which part of it failed.
>>
>> The isXxx approach works fine for the template constraint itself, but to
>> assert that a given type meets all requirements of a concept, it is not
>> very usable at all.
>
> Wouldn't it be preferable to improve the compiler to a degree, that it can
> tell, which subexpression of a constraint failed?

Two problems:

a) failing constraints do not lead to a compiler error at all but simply lead to the template being ignored. It might be possible to improve the error message if no matching template is found by listing all the templates that were ignored due to constraints. Still, this would have to be done carefully, to avoid making the message even more confusing.

b) constraints are simply general expressions that evaluate to a boolean. It is only the very special situation of chained &&-expressions that one could possibly "blame" a subexpression for the failure. I am not sure whether this situation justifies a special handling.

On 21.11.2011 13:16, Kagamin wrote:
> Norbert Nemec Wrote:
>
>> On 20.11.2011 21:07, Andrei Alexandrescu wrote:
>>> On 11/20/11 10:41 AM, Norbert Nemec wrote:
>>> [snip]
>>>
>>> Why not follow the patter of isXxx in the standard library?
>>>
>>> Andrei
>>
>> Actually, that was my starting point. However, this approach does not
>> scale up:
>>
>> A concept typically is a collection of requirements that have to be met
>> individually. A huge boolean statement inside an assertion does not give
>> any clue as to which part of it failed.
>>
>> The isXxx approach works fine for the template constraint itself, but to
>> assert that a given type meets all requirements of a concept, it is not
>> very usable at all.
>
> If an assertion fails do you want the compiler to terminate or to silently proceed to the next overload?

Not at all. Silently ignoring should only happen for constraints that evaluate to false - just like it does now.

The list of assertions is meant for the point of implementing a concept, to verify that all requirements are individually met.

As constraint, the list of assertions is packed up into a __traits(compiles,...) expression that simply turns a failing assertion into a "false" and makes the compiler silently skip and proceed.