[cfe-dev] Roadmap for a Concepts implementation P0734R0, currently merged into C++20 draft

[Saar Raz via cfe-dev]

>
>
> Concepts are not instantiated. They are evaluated for satisfaction. Much
> of the wording to allow "global" knowledge to be used for instantiating
> templates relies on point-of-instantiation.
>
> void foo(int, int);
>
> template <typename T>
> concept C = requires (T t) { ::foo(t); };
>
> constexpr bool a = C<int>;
>
> void foo(int, int = 0);
> constexpr bool b = C<int>;
>
> static_assert(a != b);
>

Mmm, good example. So does that mean we cannot hope to cache results of
concept evaluations? That sounds like quite the performance hit for highly
conceptized code (e.g. ranges), is it not?

Maybe we can form some sort of condition under which a concept evaluation
result may be cached? There are, I think, at least some expression classes
that cannot change once the concept has been instantiated with a type (e.g.
expressions that do not involve namespace lookup).
I'd say that's premature optimization but it impacts the design quite
substantially - do we model concepts specializations as Decls or not?


> My understanding is that it is viable for conjunction and disjunction to
> be represented by && and || for satisfaction checking; it would be
> context-dependent during the evaluation whether the node is within an
> atomic constraint (and thus not representative of a conjunction or
> disjunction).
>
What worries me about checking for satisfaction with && and || is the
following:
[temp.constr.atomic]: "[Example:
  template<typename T>
  concept C = sizeof(T) == 4 && !true; // requires atomic constraints
                                     // sizeof(T) == 4 and !true
  template<typename T>
  struct S {
    constexpr operator bool() const { return true; }
  };

  template<typename T>
    requires (S<T>{})
      void f(T); // #1

  void f(int); // #2

  void g() {
  f(0); // error: expression S<int>{} does not have type bool
        // while checking satisfaction of deduced arguments of #1,
        // even though #2 is a better match
  }
— end example ]"
By using regular Exprs we cannot enforce the bool-ness of operands.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171118/4a8f2bbf/attachment.html>