Re: [boost] [rfc] Unicode GSoC project

Subject: Re: [boost] [rfc] Unicode GSoC project
From: Beman Dawes (bdawes_at_[hidden])
Date: 2009-05-15 13:41:39

On Fri, May 15, 2009 at 12:09 PM, Eric Niebler <eric_at_[hidden]> wrote:
> Mathias Gaunard wrote:
>> ...
>>> The concepts are of critical importance, and these don't seem right to
>>> me. My C++0x concept-foo is weak, and I'd like to involve many more people
>>> in this discussion.
>>
>> In C++0x concept-foo, I would say associated the validity invariant with a
>> non-auto concept (i.e. the model has to specify it implements the concept,
>> unlike auto concepts which are implicitly structurally matched to models),
>> so as to distinguish ranges that aim at maintaining that invariants from
>> ranges that don't.
>
> Whoa, we're nowhere near talking about auto vs. non-auto C++0x concepts. We
> don't even have Unicode algorithms to work from, so we don't know what form
> the concepts will take. You're jumping to the end. I repeat: you don't know
> what the concepts are and you won't know until you write some concrete
> algorithms and try to lift generic implementations from them.
>
> Please have a look at: http://www.generic-programming.org/

Strongly agree.

>
>
>>> The purpose of the concepts are to allow algorithms to be implemented
>>> generically in terms of the operations provided by the concepts. So, what
>>> algorithms do we need, and how can we express them generically in terms of
>>> concepts? Without that most critical step, we'll get the concepts all wrong.
>>
>> Concepts are not just about operations, but also about semantics.
>> A single pass range and a forward range provide the same operations, but
>> they've got different semantics.
>> A single pass range can be traversed once, a forward range, which refines
>> it, can be traversed any number of times.
>
> Ahem. I know.
>
>> Refining the range concepts to create a new concept meaning a range that
>> satisfies a given predicate doesn't seem that different in spirit.
>>
>> The problem is that it is not possible to ensure that predicate
>> programmatically with range adapters, so we have to fallback to design by
>> contract.
>
> Show me the (concrete) code.

Exactly.

>
>> Now, if it is believed this is a bad idea to model invariants as a
>> concept, I simply will remove the concept and just deal with raw ranges
>> directly, without any concept(=invariant) checking.
>
> Now we're talking. Ditch the concepts. Write the algorithms. Then try to
> make them generic and *find* the concepts.

Amen.

--Beman