This is about a hypothetical feature that solves a problem with "auto
concepts". Consider this:

 // simplified example of CopyConstructible
 auto concept CopyConstructible<typename T>
 {
   T::T(const T&);
   T::~T();

   axiom CopyEquivalence(T x) {
     T(x) == x;
   }
 }

 // auto_ptr satisfies the function requirements but violates
 // the CopyEquivalence axiom. However, the compiler doesn't
 // know that.
 template<typename T>
 concept_map !CopyConstructible<std::auto_ptr<T>> {}

Why do we need negative concept maps? It allows us to override "auto
concepts" just like it's already possible to specialize some traits
class to disable the support of some specific type or types in a
generic algorithm. A negative concept_map for an auto concept would
explicitly say that the type in question doesn't satisfy the concept's
semantic requirements -- those that are hard to verify by a
compiler. ;-)

Without negative concept maps a library designer needs to write
something like this

 template<typename T> struct yes_really {
   static const bool value = true;
 };

 auto concept CopyConstructible<typename T>
 {
   T::T(const T&);
   T::~T();

   requires True<yes_really<T>::value>;

   axiom CopyEquivalente(T x) {
     T(x) == x;
   }
 }

to support overriding of auto concepts via specializations of
yes_really<>:

 template<typename T> struct yes_really<std::auto_ptr<T>> {
   static const bool value = false;
 };

IMHO, this would qualify as a "template trick" which is something we
like to get rid of in favour of concepts. Also it requires foresight.
What if the library developer forgot to add this "extension point"?
Well, he should have to write something like this to allow users to
explicitly disable some concept maps.

What do you think about "negative concept maps"?

Cheers!
SG


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

On 19 mayo, 22:41, SG <s.gesem...@gmail.com> wrote:
> This is about a hypothetical feature that solves a problem with "auto
> concepts". Consider this:
>
>  // simplified example of CopyConstructible
>  auto concept CopyConstructible<typename T>
>  {
>    T::T(const T&);
>    T::~T();
>
>    axiom CopyEquivalence(T x) {
>      T(x) == x;
>    }
>  }
>
>  // auto_ptr satisfies the function requirements but violates
>  // the CopyEquivalence axiom. However, the compiler doesn't
>  // know that.
>  template<typename T>
>  concept_map !CopyConstructible<std::auto_ptr<T>> {}
>
> Why do we need negative concept maps? It allows us to override "auto
> concepts" just like it's already possible to specialize some traits
> class to disable the support of some specific type or types in a
> generic algorithm. A negative concept_map for an auto concept would
> explicitly say that the type in question doesn't satisfy the concept's
> semantic requirements -- those that are hard to verify by a
> compiler. ;-)
>
> Without negative concept maps a library designer needs to write
> something like this
>
>  template<typename T> struct yes_really {
>    static const bool value = true;
>  };
>
>  auto concept CopyConstructible<typename T>
>  {
>    T::T(const T&);
>    T::~T();
>
>    requires True<yes_really<T>::value>;
>
>    axiom CopyEquivalente(T x) {
>      T(x) == x;
>    }
>  }
>
> to support overriding of auto concepts via specializations of
> yes_really<>:
>
>  template<typename T> struct yes_really<std::auto_ptr<T>> {
>    static const bool value = false;
>  };
>
> IMHO, this would qualify as a "template trick" which is something we
> like to get rid of in favour of concepts. Also it requires foresight.
> What if the library developer forgot to add this "extension point"?
> Well, he should have to write something like this to allow users to
> explicitly disable some concept maps.
>
> What do you think about "negative concept maps"?
>
> Cheers!
> SG
>
> --
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-...@netlab.cs.rpi.edu]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html                     ]

Axioms were almost voted out of the draft, read the discussion in the
minutes of the last (or one before the last) meeting. I also have my
doubts with axioms as currently defined (some cool research paper
somewhere shows that they have potential, but not with the current
wording of c++0x) so I'll skip them here.

I'm not sure what do you mean with "negative concept maps". I think
something like

auto concept c<typename T> { }

struct s { };
concept_map c<s> = delete;

is what you mean (which isn't allowed as far as I know).

In the ideal world I don't think they are really needed. I see auto
concepts as interface-complaint and normal concepts as semantic-
complaint. Also, a type whose "copy operation" isn't really a copy
shouldn't have a copy operation in the first place. auto_ptr is
backward-compatibility babbage (I like backward compatibility, but
after seeing unique_ptr its clear that auto_ptr isn't welcomed
anymore).


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

On 21 Mai, 07:51, micael.d...@gmail.com wrote:
> On 19 mayo, 22:41, SG <s.gesem...@gmail.com> wrote:
> >  // auto_ptr satisfies the function requirements but violates
> >  // the CopyEquivalence axiom. However, the compiler doesn't
> >  // know that.
> >  template<typename T>
> >  concept_map !CopyConstructible<std::auto_ptr<T>> {}
note the bang:   ^

> I'm not sure what do you mean with "negative concept maps". I think
> something like
>
> auto concept c<typename T> { }
>
> struct s { };
> concept_map c<s> = delete;
>
> is what you mean (which isn't allowed as far as I know).

Yes, something like that. I simply used another syntax

   concept_map !c<s> {}
   concept_map !c<s>;
   concept_map c<s> = delete;

> [...] Also, a type whose "copy operation" isn't really a copy
> shouldn't have a copy operation in the first place. auto_ptr is
> backward-compatibility babbage (I like backward compatibility, but
> after seeing unique_ptr its clear that auto_ptr isn't welcomed
> anymore).

Actually, auto_ptr<T> doesn't satisfy those concepts
(CopyConstructible, MoveConstructible, CopyAssignable, ...) becasue
its "copy-ctor" and "copy-assignment" take a reference-to-non-const.
So, it's fine and we should never have to explicitly "disable" an auto
concept_map.

Cheers!
SG

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