[cfe-dev] The state of Concepts in Clang

[Hannes Hauswedell via cfe-dev]

>>> 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.


> 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
?

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.

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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170214/6f5cd5fa/attachment.sig>