[PATCH] D41217: [Concepts] Concept Specialization Expressions

Hubert Tong via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Mar 21 15:51:15 PDT 2018


hubert.reinterpretcast added inline comments.


================
Comment at: lib/AST/ExprCXX.cpp:1478
+  {
+    // We do not want error diagnostics escaping here.
+    Sema::SFINAETrap Trap(S);
----------------
saar.raz wrote:
> hubert.reinterpretcast wrote:
> > saar.raz wrote:
> > > faisalv wrote:
> > > > Hubert: This needs a TODO: the idea is not to drop SFINAE errors, but to avoid instantiation that may trigger errors not in the immediate context of instantiation. The substitution needs to happen piecewise.
> > > Could you elaborate/give an example where this handling is inappropriate?
> > Determining satisfaction requires normalization (lazy normalization should be considered).
> > The determination of satisfaction then proceeds by handling the left-hand side of conjunction and disjunction constraints before possibly substituting into the right-hand side; i.e., there is short-circuiting behaviour.
> > 
> > Example:
> > ```
> > template <typename T>
> > concept C = true;
> > 
> > template <typename T>
> > struct Q { static constexpr T value = nullptr; };
> > 
> > template <typename T>
> > requires C<T> || T::value
> > struct A { };
> > 
> > template <typename T>
> > requires C<T> || Q<T>::value
> > struct B { };
> > 
> > A<int> a; // okay
> > B<int> b; // okay
> > ```
> > 
> OK I see your point. You said this should be a TODO - do you think this should be delayed to a further patch (namely D41569, where we actually deal with diagnostics and stuff)?
> About lazy normalization, I tend to think it is not a good idea - you'll probably check satisfaction for every defined constraint expression at some point, and do that many more times than you'd define a new one
The status quo of this patch with regards to this topic is not quite something that I would like to commit onto trunk.

As for normalization: The process is needed for distinct purposes with somewhat differing output requirements.
The order-dependent form (to check for satisfaction) can be integrated with the substitution and evaluation: that is, the output of normalization is realized in control flow, and not "stored".

The order-independent form (to check for subsumption) could be delayed until overload resolution with a constrained candidate reaches the point where determining subsumption is necessary.



Repository:
  rC Clang

https://reviews.llvm.org/D41217





More information about the cfe-commits mailing list