Quantcast

The state of Concepts in Clang

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

The state of Concepts in Clang

Philip Reames via cfe-dev
Hi everyone,

I wanted to ask what the current state of the Concepts TS is in Clang. I
saw some older list threads last year, but also didn't see much in
regard of commits, but maybe I am also looking in the wrong places.

The status page lists it as WIP, but from my own experience I know that
WIP can me anything from "we are running the last tests before release"
to "I have put it on the TODO list".

The background is that we are currently redesigning a large template
library and would really like to make use of concepts. Working with GCC
during development is not a problem, but when we start distributing
first release candidates maybe a year from now, it would be important to
have Clang support, too.

If someone could shed light on the current status and whether there is
an ETA that would help us a lot. Note that I am not implying that anyone
should do anything for us, it's just important for us to know whether
it's something we can likely expect for e.g. clang-6 or "definetely not
in the next two years".

Thank you,
Hannes
--
pgp-key: https://hannes.hauswedell.net/hannes_hauswedell_public_key.asc
fingerprint: FC35 7547 7916 DA55 DC42 27EA 1D57 8E18 A109 60BF


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The state of Concepts in Clang

Philip Reames via cfe-dev
The Concepts TS implementation for Clang is occurring on trunk; so you are looking in the right place.
Regardless of the implementation status in Clang, the TS remains an experimental design, which may be subject to change.
So, I think that using relying on the Concepts TS in production carries some risks: even if the support is there, it might not be the same as GCC or the current version of the TS.

-- HT

On Sun, Feb 5, 2017 at 8:43 AM, Hannes Hauswedell via cfe-dev <[hidden email]> wrote:
Hi everyone,

I wanted to ask what the current state of the Concepts TS is in Clang. I
saw some older list threads last year, but also didn't see much in
regard of commits, but maybe I am also looking in the wrong places.

The status page lists it as WIP, but from my own experience I know that
WIP can me anything from "we are running the last tests before release"
to "I have put it on the TODO list".

The background is that we are currently redesigning a large template
library and would really like to make use of concepts. Working with GCC
during development is not a problem, but when we start distributing
first release candidates maybe a year from now, it would be important to
have Clang support, too.

If someone could shed light on the current status and whether there is
an ETA that would help us a lot. Note that I am not implying that anyone
should do anything for us, it's just important for us to know whether
it's something we can likely expect for e.g. clang-6 or "definetely not
in the next two years".

Thank you,
Hannes
--
pgp-key: https://hannes.hauswedell.net/hannes_hauswedell_public_key.asc
fingerprint: FC35 7547 7916 DA55 DC42 27EA 1D57 8E18 A109 60BF


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The state of Concepts in Clang

Philip Reames via cfe-dev
Hi Hubert,

thanks for the reply and the "warning sign". I am aware that the
discussion on Concepts is ongoing, but there is the published ISO/IEC TS
19217:2015 that GCC implements and it has been rather stable from my
knowledge.
In any case my original question still remains: is there an ETA for
concepts in Clang? Is there a person responsible for it right now that
could have more details?

Thanks,
Hannes
--
pgp-key: https://hannes.hauswedell.net/hannes_hauswedell_public_key.asc
fingerprint: FC35 7547 7916 DA55 DC42 27EA 1D57 8E18 A109 60BF

On 05.02.2017 18:57, Hubert Tong wrote:

> The Concepts TS implementation for Clang is occurring on trunk; so you are
> looking in the right place.
> Regardless of the implementation status in Clang, the TS remains an
> experimental design, which may be subject to change.
> So, I think that using relying on the Concepts TS in production carries
> some risks: even if the support is there, it might not be the same as GCC
> or the current version of the TS.
>
> -- HT
>
> On Sun, Feb 5, 2017 at 8:43 AM, Hannes Hauswedell via cfe-dev <
> [hidden email]> wrote:
>
>> Hi everyone,
>>
>> I wanted to ask what the current state of the Concepts TS is in Clang. I
>> saw some older list threads last year, but also didn't see much in
>> regard of commits, but maybe I am also looking in the wrong places.
>>
>> The status page lists it as WIP, but from my own experience I know that
>> WIP can me anything from "we are running the last tests before release"
>> to "I have put it on the TODO list".
>>
>> The background is that we are currently redesigning a large template
>> library and would really like to make use of concepts. Working with GCC
>> during development is not a problem, but when we start distributing
>> first release candidates maybe a year from now, it would be important to
>> have Clang support, too.
>>
>> If someone could shed light on the current status and whether there is
>> an ETA that would help us a lot. Note that I am not implying that anyone
>> should do anything for us, it's just important for us to know whether
>> it's something we can likely expect for e.g. clang-6 or "definetely not
>> in the next two years".
>>
>> Thank you,
>> Hannes
>> --
>> pgp-key: https://hannes.hauswedell.net/hannes_hauswedell_public_key.asc
>> fingerprint: FC35 7547 7916 DA55 DC42 27EA 1D57 8E18 A109 60BF
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The state of Concepts in Clang

Philip Reames via cfe-dev
Hi Hannes,

At this time, I have been working on Concepts in Clang. I am not sure how "people" are using concepts in GCC, but my experience on unit testing produced a number of internal compiler errors (and I have not found the error messages to be helpful in general). Some cases of those internal compiler errors stem from the cases being underspecified in the TS.

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.

-- HT

On Thu, Feb 9, 2017 at 3:17 PM, Hannes Hauswedell <[hidden email]> wrote:
Hi Hubert,

thanks for the reply and the "warning sign". I am aware that the
discussion on Concepts is ongoing, but there is the published ISO/IEC TS
19217:2015 that GCC implements and it has been rather stable from my
knowledge.
In any case my original question still remains: is there an ETA for
concepts in Clang? Is there a person responsible for it right now that
could have more details?

Thanks,
Hannes
--
pgp-key: https://hannes.hauswedell.net/hannes_hauswedell_public_key.asc
fingerprint: FC35 7547 7916 DA55 DC42 27EA 1D57 8E18 A109 60BF

On 05.02.2017 18:57, Hubert Tong wrote:
> The Concepts TS implementation for Clang is occurring on trunk; so you are
> looking in the right place.
> Regardless of the implementation status in Clang, the TS remains an
> experimental design, which may be subject to change.
> So, I think that using relying on the Concepts TS in production carries
> some risks: even if the support is there, it might not be the same as GCC
> or the current version of the TS.
>
> -- HT
>
> On Sun, Feb 5, 2017 at 8:43 AM, Hannes Hauswedell via cfe-dev <
> [hidden email]> wrote:
>
>> Hi everyone,
>>
>> I wanted to ask what the current state of the Concepts TS is in Clang. I
>> saw some older list threads last year, but also didn't see much in
>> regard of commits, but maybe I am also looking in the wrong places.
>>
>> The status page lists it as WIP, but from my own experience I know that
>> WIP can me anything from "we are running the last tests before release"
>> to "I have put it on the TODO list".
>>
>> The background is that we are currently redesigning a large template
>> library and would really like to make use of concepts. Working with GCC
>> during development is not a problem, but when we start distributing
>> first release candidates maybe a year from now, it would be important to
>> have Clang support, too.
>>
>> If someone could shed light on the current status and whether there is
>> an ETA that would help us a lot. Note that I am not implying that anyone
>> should do anything for us, it's just important for us to know whether
>> it's something we can likely expect for e.g. clang-6 or "definetely not
>> in the next two years".
>>
>> Thank you,
>> Hannes
>> --
>> pgp-key: https://hannes.hauswedell.net/hannes_hauswedell_public_key.asc
>> fingerprint: FC35 7547 7916 DA55 DC42 27EA 1D57 8E18 A109 60BF
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The state of Concepts in Clang

Philip Reames via cfe-dev
Hi Hubert,

> At this time, I have been working on Concepts in Clang.

Ah, great to know!

>  I am not sure how
> "people" are using concepts in GCC, but my experience on unit testing
> produced a number of internal compiler errors

Up until now it has worked ok for me, but I have mostly used rather
basic concepts and only mild "specialization" of concepts.

> (and I have not found the error messages to be helpful in general).

True, but that's something where clang had to lead the way before, too,
or not? :)

> Some cases of those internal
> compiler errors stem from the cases being underspecified in the TS.
>

Haven't had any of those because of concepts, yet.

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

Thanks for the info and of course for working on this,
Hannes


>
> On Thu, Feb 9, 2017 at 3:17 PM, Hannes Hauswedell <[hidden email]>
> wrote:
>
>> Hi Hubert,
>>
>> thanks for the reply and the "warning sign". I am aware that the
>> discussion on Concepts is ongoing, but there is the published ISO/IEC TS
>> 19217:2015 that GCC implements and it has been rather stable from my
>> knowledge.
>> In any case my original question still remains: is there an ETA for
>> concepts in Clang? Is there a person responsible for it right now that
>> could have more details?
>>
>> Thanks,
>> Hannes
>> --
>> pgp-key: https://hannes.hauswedell.net/hannes_hauswedell_public_key.asc
>> fingerprint: FC35 7547 7916 DA55 DC42 27EA 1D57 8E18 A109 60BF
>>
>> On 05.02.2017 18:57, Hubert Tong wrote:
>>> The Concepts TS implementation for Clang is occurring on trunk; so you
>> are
>>> looking in the right place.
>>> Regardless of the implementation status in Clang, the TS remains an
>>> experimental design, which may be subject to change.
>>> So, I think that using relying on the Concepts TS in production carries
>>> some risks: even if the support is there, it might not be the same as GCC
>>> or the current version of the TS.
>>>
>>> -- HT
>>>
>>> On Sun, Feb 5, 2017 at 8:43 AM, Hannes Hauswedell via cfe-dev <
>>> [hidden email]> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> I wanted to ask what the current state of the Concepts TS is in Clang. I
>>>> saw some older list threads last year, but also didn't see much in
>>>> regard of commits, but maybe I am also looking in the wrong places.
>>>>
>>>> The status page lists it as WIP, but from my own experience I know that
>>>> WIP can me anything from "we are running the last tests before release"
>>>> to "I have put it on the TODO list".
>>>>
>>>> The background is that we are currently redesigning a large template
>>>> library and would really like to make use of concepts. Working with GCC
>>>> during development is not a problem, but when we start distributing
>>>> first release candidates maybe a year from now, it would be important to
>>>> have Clang support, too.
>>>>
>>>> If someone could shed light on the current status and whether there is
>>>> an ETA that would help us a lot. Note that I am not implying that anyone
>>>> should do anything for us, it's just important for us to know whether
>>>> it's something we can likely expect for e.g. clang-6 or "definetely not
>>>> in the next two years".
>>>>
>>>> Thank you,
>>>> Hannes
>>>> --
>>>> pgp-key: https://hannes.hauswedell.net/hannes_hauswedell_public_key.asc
>>>> fingerprint: FC35 7547 7916 DA55 DC42 27EA 1D57 8E18 A109 60BF
>>>>
>>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> [hidden email]
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>
>>>>
>>>
>>
>>
>>
>

--
pgp-key: https://hannes.hauswedell.net/hannes_hauswedell_public_key.asc
fingerprint: FC35 7547 7916 DA55 DC42 27EA 1D57 8E18 A109 60BF


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The state of Concepts in Clang

Philip Reames via cfe-dev
On Thu, Feb 9, 2017 at 4:59 PM, Hannes Hauswedell <[hidden email]> wrote:
Hi Hubert,

> At this time, I have been working on Concepts in Clang.

Ah, great to know!

>  I am not sure how
> "people" are using concepts in GCC, but my experience on unit testing
> produced a number of internal compiler errors

Up until now it has worked ok for me, but I have mostly used rather
basic concepts and only mild "specialization" of concepts.

> (and I have not found the error messages to be helpful in general).

True, but that's something where clang had to lead the way before, too,
or not? :)

> Some cases of those internal
> compiler errors stem from the cases being underspecified in the TS.
>

Haven't had any of those because of concepts, yet.

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

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.

As for the Clang implementation, we have (at least a sketch of) a plan, but no idea how difficult it is to execute.
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.
 

Thanks for the info and of course for working on this,
Hannes


>
> On Thu, Feb 9, 2017 at 3:17 PM, Hannes Hauswedell <[hidden email]>
> wrote:
>
>> Hi Hubert,
>>
>> thanks for the reply and the "warning sign". I am aware that the
>> discussion on Concepts is ongoing, but there is the published ISO/IEC TS
>> 19217:2015 that GCC implements and it has been rather stable from my
>> knowledge.
>> In any case my original question still remains: is there an ETA for
>> concepts in Clang? Is there a person responsible for it right now that
>> could have more details?
>>
>> Thanks,
>> Hannes
>> --
>> pgp-key: https://hannes.hauswedell.net/hannes_hauswedell_public_key.asc
>> fingerprint: FC35 7547 7916 DA55 DC42 27EA 1D57 8E18 A109 60BF
>>
>> On 05.02.2017 18:57, Hubert Tong wrote:
>>> The Concepts TS implementation for Clang is occurring on trunk; so you
>> are
>>> looking in the right place.
>>> Regardless of the implementation status in Clang, the TS remains an
>>> experimental design, which may be subject to change.
>>> So, I think that using relying on the Concepts TS in production carries
>>> some risks: even if the support is there, it might not be the same as GCC
>>> or the current version of the TS.
>>>
>>> -- HT
>>>
>>> On Sun, Feb 5, 2017 at 8:43 AM, Hannes Hauswedell via cfe-dev <
>>> [hidden email]> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> I wanted to ask what the current state of the Concepts TS is in Clang. I
>>>> saw some older list threads last year, but also didn't see much in
>>>> regard of commits, but maybe I am also looking in the wrong places.
>>>>
>>>> The status page lists it as WIP, but from my own experience I know that
>>>> WIP can me anything from "we are running the last tests before release"
>>>> to "I have put it on the TODO list".
>>>>
>>>> The background is that we are currently redesigning a large template
>>>> library and would really like to make use of concepts. Working with GCC
>>>> during development is not a problem, but when we start distributing
>>>> first release candidates maybe a year from now, it would be important to
>>>> have Clang support, too.
>>>>
>>>> If someone could shed light on the current status and whether there is
>>>> an ETA that would help us a lot. Note that I am not implying that anyone
>>>> should do anything for us, it's just important for us to know whether
>>>> it's something we can likely expect for e.g. clang-6 or "definetely not
>>>> in the next two years".
>>>>
>>>> Thank you,
>>>> Hannes
>>>> --
>>>> pgp-key: https://hannes.hauswedell.net/hannes_hauswedell_public_key.asc
>>>> fingerprint: FC35 7547 7916 DA55 DC42 27EA 1D57 8E18 A109 60BF
>>>>
>>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> [hidden email]
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>
>>>>
>>>
>>
>>
>>
>


--
pgp-key: https://hannes.hauswedell.net/hannes_hauswedell_public_key.asc
fingerprint: FC35 7547 7916 DA55 DC42 27EA 1D57 8E18 A109 60BF



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The state of Concepts in Clang

Philip Reames 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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The state of Concepts in Clang

Philip Reames via cfe-dev
On Tue, Feb 14, 2017 at 10:24 AM, Hannes Hauswedell <[hidden email]> 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



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The state of Concepts in Clang

Philip Reames via cfe-dev
In reply to this post by Philip Reames via cfe-dev
On 2/14/2017 10:24 AM, Hannes Hauswedell via cfe-dev wrote:
> 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'll note that the Ranges proposal [1] exclusively specifies function
concepts.

Tom.

[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4620.pdf
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The state of Concepts in Clang

Philip Reames via cfe-dev
On Wed, Feb 15, 2017 at 4:24 PM, Tom Honermann <[hidden email]> wrote:
On 2/14/2017 10:24 AM, Hannes Hauswedell via cfe-dev wrote:
> 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'll note that the Ranges proposal [1] exclusively specifies function
concepts.
Which makes sense if you believe in overloading concept names.

There's a proposal (not yet reviewed by the committee) on (characterization mine) being more conservative about how Concepts are in C++:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0587r0.pdf

-- HT


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The state of Concepts in Clang

Philip Reames via cfe-dev
On 2/15/2017 5:37 PM, Hubert Tong wrote:

> On Wed, Feb 15, 2017 at 4:24 PM, Tom Honermann
> <[hidden email] <mailto:[hidden email]>>
> wrote:
>
>     On 2/14/2017 10:24 AM, Hannes Hauswedell via cfe-dev wrote:
>     > 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'll note that the Ranges proposal [1] exclusively specifies function
>     concepts.
>
> Which makes sense if you believe in overloading concept names.
>
> There's a proposal (not yet reviewed by the committee) on
> (characterization mine) being more conservative about how Concepts are
> in C++:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0587r0.pdf
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.open-2Dstd.org_jtc1_sc22_wg21_docs_papers_2017_p0587r0.pdf&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=G16pPyziSz-5a5VnAMGWoEN2qIMOptadgDXbtSjlFFQ&m=FwFNsszDoQwt2HTgWbTyqrnZvODp7S_UH898DjFoYUo&s=ZQKCWxPSnxNrL9UaeFBw5BZdcx_gphNnAkxVqWhe1Zs&e=>

As well as the following ones that also have not yet been reviewed:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0324r0.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0464r1.html

Tom.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Loading...