[cfe-dev] The state of Concepts in Clang

[Hubert Tong via cfe-dev]

On Tue, Feb 14, 2017 at 10:24 AM, Hannes Hauswedell <h2+lists2017 at fsfe.org>
wrote:

> >>> I am not sure an ETA makes sense if the shape of what is going to be
> >>> delivered is changing. For example, the TS has a one-size-fits-all
> >>> normalization process which can be overly eager; part of the Clang
> >>> implementation effort would be to implement (in consultation with the
> >>> committee) the intended behaviour for each of the uses of
> normalization.
> >>
> >> TBH honest I have no real clue of the scope of implementing the TS fully
> >> in Clang (or what the current progress is) so I am not *suggesting*
> >> anything, but maybe if there was a preliminary usable release in Clang
> >> it would get in more testers and help diagnose issues and corner cases?
> >> I thought this was what the committee wanted and why so many things
> >> didn't make it into C++17, i.e. getting people to use TSes early so that
> >> issues can be found and solved before integration into the proper
> >> standard...
> >> Then again, maybe you already know the rough edges well and would rather
> >> figure them out first?
> >>
> > I'm hoping that the roughest of the edges in what the TS is would be
> > smoothed out before too much effort is spent on things which do not
> > translate (in terms of reusability or implementation/usage experience) to
> > later versions.
> > In some cases, like with concept definitions being also variable or
> > function templates, extra baggage comes from the existing parts of the
> > language.
> >
> > The goal, of course, is to have something available for feedback so that
> we
> > know if the decisions made are ones which work for users.
> > The take away from that though, is that early adopters are, in a sense,
> > beta testing.
>
> Yes, that's ok, I was expecting that.
>
> > My inclination for writing concepts code (for use, not testing) right now
> > would be to use function concepts only, limit overloading concept names,
> > avoid abbreviated function template syntax, and avoid template
> > introductions.
> > I would also be very conservative in how I form constraints which are
> > intended to be "more specific" or "more general" than other constraints.
>
> Thank you for these suggestions, we will keep them in mind when drafting
> a first design for the new library!
>
> > As for the Clang implementation, we have (at least a sketch of) a plan,
> but
> > no idea how difficult it is to execute.
>
> Ok, cool, let's see. Development happens in trunk, right? So we'll get
> it through snapshots. We will start doing CI in early summer and can
> report on differences in behviour vs GCC.
>
Development does happen on trunk. I am not entirely sure that the
implementation would be ready to consume a concept-enabled library at that
time.


>
>
> > I think there is at least one feature missing from the current TS which
> is
> > needed: a way to refer to template parameters which are being specialized
> > in a specialization.
> >
>
> Hm, you mean something like this:
>
> ```
> template <typename T1>
> concept bool My_int_concept()
> {
>     return false;
> }
>
> template <> // how to explicitly overload for int?
> concept bool My_int_concept()
> {
>     return true;
> }
> ```
>
> ?
>
> Or do you mean specialization as in 2) of
> http://en.cppreference.com/w/cpp/language/constraints#Concept_resolution
> ?
>
Neither.

Given:
template <typename T>
struct A {
  void foo() requires OkayA<T> || T::okay;
  void foo() requires OkayB<T>;
};

How would you explicitly specialize the first A<int>::foo?

template <>
void A<int>::foo() requires OkayA<int> || int::okay // seems wrong
{ }


>
> I previously planned designing concepts as variables and don't yet see
> the added flexibility of the function interface as really important, but
> I agree that it adds consistency to also have function concepts.
>
I am not sure that concept definitions should be variable or functions at
all.
My interpretation of the function concepts is that they are a shortcut in
the specification to allow for overloading of concept names.


>
> Regards,
> Hannes
> --
> pgp-key: https://hannes.hauswedell.net/hannes_hauswedell_public_key.asc
> fingerprint: FC35 7547 7916 DA55 DC42 27EA 1D57 8E18 A109 60BF
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170214/0adb61d5/attachment.html>