During a recent discussion I observed that the most
recent revision of the concepts utilities proposal, that is

http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2082.pdf

defines the concept CopyConstructible by the following
language concept and additional, explanatory text:

----------------------------------
20.1.3 Copy construction [lib.copyconstructible]

1 Concept CopyConstructible requires the ability to create and destroy
copies of an object. 1)

auto concept CopyConstructible<typename T> {
  T::T(T);  2)
  T::~T();
};

with footnotes:

(1) Table 30 also contains the valid expressions &t and &u. However,
we omit these requirements because we need references to model
CopyConstructible.

(2) This signature also covers construction from a non-const value of
type T.
----------------------------------

This description does not say anything about the *effect* of
T::(const T&), in contrast to the current 14882:2003 standard,
which says in Table 30, 20.1.3:

"t is equivalent to T(t)"

Question: Is this omission deliberate or an oversight?

Greetings from Bremen,

Daniel Kr   gler


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

===================================== MODERATOR'S COMMENT:

(And this is the third time I've approved the post;
the moderation problem clearly needs to be resolved!)


===================================== END OF MODERATOR'S COMMENT
[ This will be my 3rd attempt to reply... ]

On Apr 26, 6:23 pm, Daniel Kr   gler <daniel.krueg...@googlemail.com>
wrote:
> This description does not say anything about the *effect* of
> T::(const T&), in contrast to the current 14882:2003 standard,
> which says in Table 30, 20.1.3:
>
> "t is equivalent to T(t)"
>
> Question: Is this omission deliberate or an oversight?

It was an oversight. I believe we will express this requirement as an
axiom.

  - Doug


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

===================================== MODERATOR'S COMMENT:



===================================== END OF MODERATOR'S COMMENT
On 3 Mai, 18:26, Douglas Gregor <doug.gre...@gmail.com> wrote:
> On Apr 26, 6:23 pm, Daniel Kr   gler <daniel.krueg...@googlemail.com>
> wrote:
>
> > This description does not say anything about the *effect* of
> > T::(const T&), in contrast to the current 14882:2003 standard,
> > which says in Table 30, 20.1.3:
>
> > "t is equivalent to T(t)"
>
> > Question: Is this omission deliberate or an oversight?
>
> It was an oversight. I believe we will express this requirement as an
> axiom.

Hmmh, I assume you mean something along the lines
of this (from N2193, sect. 7.6.1.4):

concept CopyConstructible<typename T> {
  T::T(const T&);
  axiom CopyEquivalence(T x) {
    T(x) == x; // okay, uses implicit ==
  }
}

I must say that I have problems understanding
the meaning of == and != in axioms, even if
the rules are specified in 7.6.1.4/2:

"Within the body of an axiom-definition, equality (==)
and inequality (!=) operators are available for each
concept type parameter and associated type T.[..]"

How does this work, if T is *not* EqualityComparable?

I would understand, if we would (a) define a proper
concept for EquivalenceRelation, e.g. using the
well-known triad of reflexivity, symmmetry, and
transititvity, e.g.

concept EquivalenceRelation<typename Op, typename T> {
  bool operator()(Op, T, T);
  axiom Reflexivity(Op op, T x) { op(x, x); }
  axiom Symmetry(Op op, T x, T y) { op(x, y) == op(y, x); }
  axiom Transitivity(Op op, T x, T y, T z) {
    if (op(x, y) && op(y, z)) op(x, z) == true;
  }
}

and (b) would use this concept inside the definition
of CopyConstructible. Regrettably, the following is
probably invalid Concept C++:

concept CopyConstructible<typename T> {
  T::T(const T&);
  template <typename Op>
  requires EquivalenceRelation<Op, T>
  axiom CopyEquivalence(T x, Op rel) {
    rel(T(x), x);
  }
}

To repair that I could simply create a valid analogon
by *generalizing* CopyConstructible in this way:

concept CopyConstructible<typename T, typename Op> {
  T::T(const T&);
  requires EquivalenceRelation<Op, T>;
  axiom CopyEquivalence(T x, Op rel) { rel(T(x), x); }
}

or in that one:

concept CopyConstructible<typename T> {
  T::T(const T&);
  typename equivalence_relation;
  requires EquivalenceRelation<equivalence_relation, T>;
  axiom CopyEquivalence(T x, equivalence_relation rel) {
    rel(T(x), x);
  }
}

but both solutions require that we provide an
associated equivalence relation with the actual
type.

What have I misunderstood here?

Another point: Assume that we define above
mentioned concept EquivalenceRelation, could
or should we add a *fourth* axiom Identity in the
following way:

concept EquivalenceRelation<typename Op, typename T> {
  ... // As before
  axiom Identity(Op op, T x, T y) { if (&x == &y) op(x, y) == true; }
}

?

I assume thate there is a problem because the axiom might
not be generally valid if we consider some possible user-defined
types e.g.

class UnAddressable {
  void operator&(); // private and *not* defined
  void operator&() const; // private and *not* defined
}

Is it possible to put a further condition in the signature of
an axiom? Consider:

auto concept Addressable<typename T> { ... }

concept EquivalenceRelation<typename Op, typename T> {
  ... // As before
  axiom Identity(Op op, Addressable<T> x, Addressable<T> y) {  // Not
legal!
    if (&x == &y) op(x, y) == true;
  }
}

So how do we say: An axiom is valid, *iff* a further requirement
applies?

Greetings from Bremen,

Daniel



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

===================================== MODERATOR'S COMMENT:
 (This note added to bypass Cox's broken spam filtering)


===================================== END OF MODERATOR'S COMMENT
On May 4, 1:55 am, Daniel Kr   gler <daniel.krueg...@googlemail.com>
wrote:
> I must say that I have problems understanding
> the meaning of == and != in axioms, even if
> the rules are specified in 7.6.1.4/2:
>
> "Within the body of an axiom-definition, equality (==)
> and inequality (!=) operators are available for each
> concept type parameter and associated type T.[..]"
>
> How does this work, if T is *not* EqualityComparable?

We assume '==' is an equivalence relation. That should be in the
wording.

> So how do we say: An axiom is valid, *iff* a further requirement
> applies?

The grammar prohibits most of your attempts to express this kind of
requirement. It can probably be expressed through auxiliary concepts
and concept maps, although it would be unwieldy. That said, it's
probably a small matter to extend the concept system in this
direction. Whether it will be useful or not... I'm not sure.

  - Doug


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]