Boost logo

Boost :

Subject: Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
From: Roland Bock (rbock_at_[hidden])
Date: 2014-08-05 08:02:44

On 2014-08-05 13:48, Mostafa wrote:
> On Tue, 05 Aug 2014 04:27:31 -0700, Roland Bock <rbock_at_[hidden]> wrote:
>> On 2014-08-05 12:14, Mostafa wrote:
>>> On Tue, 05 Aug 2014 01:59:34 -0700, Roland Bock <rbock_at_[hidden]>
>>> wrote:
>>>> On 2014-08-05 10:30, Krzysztof Czainski wrote:
>>>>> 2014-08-05 6:33 GMT+02:00 Michael Shepanski <mps_at_[hidden]>:
>>>>>> On 5/08/2014 1:39 AM, Roland Bock wrote:
>>>>>>> On 2014-08-04 13:32, Mostafa wrote:
>>>>>>>> Concepts are sets of types
>>>>>>> I think you are mistaken. A concept is a set of requirements,
>>>>>> I am under a New Year's resolution not to start philosophical
>>>>>> arguments,
>>>>>> but this one has already begun, so ...
>>>>> Please don't forget, that not all requirements can be checked at
>>>>> compile
>>>>> time. For example: TotallyOrdered. Just by checking, that an
>>>>> expression
>>>>> (a<b) is valid and yields something boolable, you can't distinguish
>>>>> between
>>>>> TotallyOrdered, PartiallyOrdered, or maybe neiter.
>>>>> So, while I think it doesn't matter, whether we view concepts as
>>>>> sets of
>>>>> types or requirements
>>>> Well, if you consider TotallyOrdered a concept, then by this
>>>> reasoning,
>>>> it cannot be a set of types. But it could be a set of requirements :-)
>>> Yes it can. TotallyOrdered := { T | if a,b,c are objects of T then
>>> ... }
>> As Kris pointed out: Whether an object is TotallyOrdered or not cannot
>> be checked at compile time because it does not depend on the type alone,
>> it also depends on runtime information. Hence, not a set of types.
> That's irrelevant. My original definition of concepts can easily be
> expanded to remove the compile time determinability restriction. Then,
> TotallyOrdered as a set of types does conceptually exist, and can be
> effectively used as a documentation tool. The concept TotallyOrdered
> may not depend on the *static* information of the type, but it sure
> does depend on objects of the type, and, ergo, it depends on the type.

It depends on properties of the type/object. That's what requirements
are for.

Anyway, sorry, I can't continue here. See you in another thread :-)

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