Re: [boost] [contract] toward N3351 concepts

Subject: Re: [boost] [contract] toward N3351 concepts
From: Evgeny Panasyuk (evgeny.panasyuk_at_[hidden])
Date: 2012-10-10 13:22:54

Hello,

09.10.2012 12:04, Andrzej Krzemienski wrote:
>> Currently, I inclined to following approach:
>> 1. Compiler MUST not do any checks on axioms besides syntactic.
>> 2. User has ALL responsibility on verifying axioms.
>> 3. Compiler has rights to exploit any knowledge which it gets from axioms,
>> regardless of fact if type fulfil them or not.
>> I.e. in following example:
> Again, under the interpretation in N2887, I would say that you are right
> about points (1) and (3), but not necessarily by (2). That is, you are
> right that no-one else besides the guy that instantiates the constrained
> template has any responsibility, but such a user does not have to make sure
> that the axioms hold either: in fact he may deliberately request the
> instantiation because he knows the axioms do not hold and he wants to make
> use of this!

Oops, yes, I definitely agree. I had in mind what you say.
I should wrote instead something like:
2. User has ALL responsibility on verifying axioms or accepting all 
side-effects of applied transformations based on axioms.

>> What I would like also to see, or at least to discuss, is requirement to
>> explicitly state that type fulfils axioms. Maybe something similar to
>> non-intrusive traits approach.
>> That would be more robust than requirements only at algorithms side which
>> are silently accepted. That would also allow us to overload functions on
>> axioms too.
>> For instance some types may have exactly same syntactic requirements, but
>> fulfil different axioms. In general compiler can't check axioms, so it
>> can't select right overload.
>> If axioms would be not used for overload, then we have to "duplicate" them
>> with traits.
> The previous concept proposals offered concept maps for this purpose. For
> instance n2906 suggested the following solution: by default concepts are
> implicit (auto-concepts), but concept refinements that differ from their
> bases only by axioms are defined as explicit, and you need to use a concept
> map to state that your type models the refined concept.
> N3351<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3351.pdf>suggests
> the use of tags for this purpose: in short, you turn an axiom set
> into a bit artificial small syntactic requirement. One could think of a
> separate language feature for this purpose, but if such axiom-only concept
> refinements are rare it may not be worth the effort.
>

Yes, I saw this "Derived" trick:

concept ForwardIterator<InputIterator I> =
Incrementable<I> &&
Derived<IteratorCategory<I>, forward_iterator_tag>;

and

concept InputIterator<WeakInputIterator I> =
EqualityComparable<I> &&
Derived<IteratorCategory<I>, input_iterator_tag>;

as I said: "If axioms would be not used for overload, then we have to 
"duplicate" them with traits. "
And here, traits are used: IteratorCategory.
Such approach forces us to make duplication:
1. Write axioms
2. Write auxiliary type traits, which in fact implicitly represent 
axioms - in order to just have overload.
With some kind of language support these two, can be merged together - 
we will not just specialize some auxiliary traits, but we will 
explicitly state that type fulfils axiom.

But I agree with you, if axiom-based overloading very rarely required - 
it does not worth of standardizing effort (but still should be kept in 
mind).

Best Regards,
Evgeny