<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 14, 2017 at 10:24 AM, Hannes Hauswedell <span dir="ltr"><<a href="mailto:h2+lists2017@fsfe.org" target="_blank">h2+lists2017@fsfe.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">>>> I am not sure an ETA makes sense if the shape of what is going to be<br>
>>> delivered is changing. For example, the TS has a one-size-fits-all<br>
>>> normalization process which can be overly eager; part of the Clang<br>
>>> implementation effort would be to implement (in consultation with the<br>
>>> committee) the intended behaviour for each of the uses of normalization.<br>
>><br>
>> TBH honest I have no real clue of the scope of implementing the TS fully<br>
>> in Clang (or what the current progress is) so I am not *suggesting*<br>
>> anything, but maybe if there was a preliminary usable release in Clang<br>
>> it would get in more testers and help diagnose issues and corner cases?<br>
>> I thought this was what the committee wanted and why so many things<br>
>> didn't make it into C++17, i.e. getting people to use TSes early so that<br>
>> issues can be found and solved before integration into the proper<br>
>> standard...<br>
>> Then again, maybe you already know the rough edges well and would rather<br>
>> figure them out first?<br>
>><br>
> I'm hoping that the roughest of the edges in what the TS is would be<br>
> smoothed out before too much effort is spent on things which do not<br>
> translate (in terms of reusability or implementation/usage experience) to<br>
> later versions.<br>
> In some cases, like with concept definitions being also variable or<br>
> function templates, extra baggage comes from the existing parts of the<br>
> language.<br>
><br>
> The goal, of course, is to have something available for feedback so that we<br>
> know if the decisions made are ones which work for users.<br>
> The take away from that though, is that early adopters are, in a sense,<br>
> beta testing.<br>
<br>
</div></div>Yes, that's ok, I was expecting that.<br>
<span class=""><br>
> My inclination for writing concepts code (for use, not testing) right now<br>
> would be to use function concepts only, limit overloading concept names,<br>
> avoid abbreviated function template syntax, and avoid template<br>
> introductions.<br>
> I would also be very conservative in how I form constraints which are<br>
> intended to be "more specific" or "more general" than other constraints.<br>
<br>
</span>Thank you for these suggestions, we will keep them in mind when drafting<br>
a first design for the new library!<br>
<span class=""><br>
> As for the Clang implementation, we have (at least a sketch of) a plan, but<br>
> no idea how difficult it is to execute.<br>
<br>
</span>Ok, cool, let's see. Development happens in trunk, right? So we'll get<br>
it through snapshots. We will start doing CI in early summer and can<br>
report on differences in behviour vs GCC.<br></blockquote><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> I think there is at least one feature missing from the current TS which is<br>
> needed: a way to refer to template parameters which are being specialized<br>
> in a specialization.<br>
><br>
<br>
</span>Hm, you mean something like this:<br>
<br>
```<br>
template <typename T1><br>
concept bool My_int_concept()<br>
{<br>
    return false;<br>
}<br>
<br>
template <> // how to explicitly overload for int?<br>
concept bool My_int_concept()<br>
{<br>
    return true;<br>
}<br>
```<br>
<br>
?<br>
<br>
Or do you mean specialization as in 2) of<br>
<a href="http://en.cppreference.com/w/cpp/language/constraints#Concept_resolution" rel="noreferrer" target="_blank">http://en.cppreference.com/w/<wbr>cpp/language/constraints#<wbr>Concept_resolution</a><br>
?<br></blockquote><div>Neither.<br><br></div><div>Given:<br></div><div><span style="font-family:monospace,monospace">template <typename T><br></span></div><div><span style="font-family:monospace,monospace">struct A {<br></span></div><div><span style="font-family:monospace,monospace">  void foo() requires OkayA<T> || T::okay;<br></span></div><div><span style="font-family:monospace,monospace">  void foo() requires OkayB<T>;<br>};</span><br></div><div><br></div><div>How would you explicitly specialize the first A<int>::foo?<br><span style="font-family:monospace,monospace"><br></span></div><div><span style="font-family:monospace,monospace">template <><br></span></div><div><span style="font-family:monospace,monospace">void A<int>::foo() requires OkayA<int> || int::okay // seems wrong<br>{ }</span><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I previously planned designing concepts as variables and don't yet see<br>
the added flexibility of the function interface as really important, but<br>
I agree that it adds consistency to also have function concepts.<br></blockquote><div>I am not sure that concept definitions should be variable or functions at all.<br></div><div>My interpretation of the function concepts is that they are a shortcut in the specification to allow for overloading of concept names.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
<div class="HOEnZb"><div class="h5">Hannes<br>
--<br>
pgp-key: <a href="https://hannes.hauswedell.net/hannes_hauswedell_public_key.asc" rel="noreferrer" target="_blank">https://hannes.hauswedell.net/<wbr>hannes_hauswedell_public_key.<wbr>asc</a><br>
fingerprint: FC35 7547 7916 DA55 DC42 27EA 1D57 8E18 A109 60BF<br>
<br>
</div></div></blockquote></div><br></div></div>