Date: Thu, 20 Jun 2013 16:37:37 -0700
On Thu, Jun 20, 2013 at 4:30 PM, Thomas Plum <tplum_at_[hidden]> wrote:
> Would someone please clarify the choices that are currently on the table?
>
> Some of the proposals are supporting __has_feature , and some are supporting __has_include .
>
> Or is there one proposal, and it is supporting both names?
Just a typo. All references to __has_feature in this thread should say
__has_include.
> I thought there was a consensus recently that macro names would be pre-defined by any compiler that implements the SG10 recommendations (?)
>
>
>> -----Original Message-----
>> From: features-bounces_at_[hidden] [mailto:features-bounces_at_open-
>> std.org] On Behalf Of John Spicer
>> Sent: Thursday, June 20, 2013 3:42 AM
>> To: Nelson, Clark
>> Cc: features_at_[hidden]
>> Subject: Re: [SG10] __has_include
>>
>>
>> On Jun 19, 2013, at 9:02 PM, "Nelson, Clark" <clark.nelson_at_[hidden]>
>> wrote:
>>
>> >>> The advantage is to all users of a compiler that's not based on
>> >> one of those
>> >>> two front ends. (Again, that seems so obvious that I'm
>> >> suspecting some sort
>> >>> of misunderstanding.)
>> >>
>> >> Those users would benefit more from us recommending that
>> >> implementations provide __has_feature than they would from us
>> >> recommending that implementations provide these two macros in
>> >> <cstddef>.
>> >
>> > Let's be really, really clear. Those users will not, strictly
>> speaking,
>> > benefit from our making a recommendation. They will benefit from
>> their
>> > implementer(s) actually following that recommendation. And it is
>> inevitable
>> > that, at least in some cases, there will be a delay before that
>> happens. I'm
>> > concerned about what happens in the interim.
>> >
>> >> If we have the former, I don't see value in the latter, so
>> >> I don't see value in us recommending both (just a burden on us to
>> >> keep around those two vestigial macros forever).
>> >
>> > The value is in the interim before everyone has an implementation of
>> > __has_include.
>> >
>> >>> We're not going to have another teleconference before the
>> >> mailing, so we're
>> >>> going to have to try to develop/recognize consensus on this
>> >> point over the
>> >>> reflector.
>> >>
>> >> Are there options on the table other than __has_feature and macros
>> >> in <cstddef>?
>> >
>> > Not at the moment, at least. All I'm saying is that people should
>> express
>> > up-or-down opinions even if they don't have anything else to
>> contribute to
>> > the discussion, to make sure we have a significant sample size.
>> >
>> >> Per above, I'm personally in favor of __has_feature, and I'm
>> >> weakly
>> >> opposed to macros in <cstddef> if we have __has_feature.
>> >
>> > In case it's not already obvious, I'm strongly in favor of the
>> macros, and
>> > weakly in favor of __has_feature in addition.
>> >
>>
>> I am in favor of the __has_include solution. We're talking about a
>> very narrow part of the whole proposal, which is the issue of dealing
>> with the presence of new headers.
>>
>> The recommendation we discussed on the teleconference was to use
>> __has_include. While it is true that only a few implementations have
>> that currently, it is reasonable to expect that other implementations
>> will add it as they add support for the other macros we suggest.
>>
>> After all, 2 compilers with __has_include is better than the zero
>> compilers that define the other macros we are recommending :-)
>>
>> I am very troubled by the <cstddef> vs. <stddef.h> issue that was
>> brought up and consider that a compelling reason not to introduce
>> macros into either or both of those headers.
>>
>> John.
>>
>> _______________________________________________
>> Features mailing list
>> Features_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/features
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features
> Would someone please clarify the choices that are currently on the table?
>
> Some of the proposals are supporting __has_feature , and some are supporting __has_include .
>
> Or is there one proposal, and it is supporting both names?
Just a typo. All references to __has_feature in this thread should say
__has_include.
> I thought there was a consensus recently that macro names would be pre-defined by any compiler that implements the SG10 recommendations (?)
>
>
>> -----Original Message-----
>> From: features-bounces_at_[hidden] [mailto:features-bounces_at_open-
>> std.org] On Behalf Of John Spicer
>> Sent: Thursday, June 20, 2013 3:42 AM
>> To: Nelson, Clark
>> Cc: features_at_[hidden]
>> Subject: Re: [SG10] __has_include
>>
>>
>> On Jun 19, 2013, at 9:02 PM, "Nelson, Clark" <clark.nelson_at_[hidden]>
>> wrote:
>>
>> >>> The advantage is to all users of a compiler that's not based on
>> >> one of those
>> >>> two front ends. (Again, that seems so obvious that I'm
>> >> suspecting some sort
>> >>> of misunderstanding.)
>> >>
>> >> Those users would benefit more from us recommending that
>> >> implementations provide __has_feature than they would from us
>> >> recommending that implementations provide these two macros in
>> >> <cstddef>.
>> >
>> > Let's be really, really clear. Those users will not, strictly
>> speaking,
>> > benefit from our making a recommendation. They will benefit from
>> their
>> > implementer(s) actually following that recommendation. And it is
>> inevitable
>> > that, at least in some cases, there will be a delay before that
>> happens. I'm
>> > concerned about what happens in the interim.
>> >
>> >> If we have the former, I don't see value in the latter, so
>> >> I don't see value in us recommending both (just a burden on us to
>> >> keep around those two vestigial macros forever).
>> >
>> > The value is in the interim before everyone has an implementation of
>> > __has_include.
>> >
>> >>> We're not going to have another teleconference before the
>> >> mailing, so we're
>> >>> going to have to try to develop/recognize consensus on this
>> >> point over the
>> >>> reflector.
>> >>
>> >> Are there options on the table other than __has_feature and macros
>> >> in <cstddef>?
>> >
>> > Not at the moment, at least. All I'm saying is that people should
>> express
>> > up-or-down opinions even if they don't have anything else to
>> contribute to
>> > the discussion, to make sure we have a significant sample size.
>> >
>> >> Per above, I'm personally in favor of __has_feature, and I'm
>> >> weakly
>> >> opposed to macros in <cstddef> if we have __has_feature.
>> >
>> > In case it's not already obvious, I'm strongly in favor of the
>> macros, and
>> > weakly in favor of __has_feature in addition.
>> >
>>
>> I am in favor of the __has_include solution. We're talking about a
>> very narrow part of the whole proposal, which is the issue of dealing
>> with the presence of new headers.
>>
>> The recommendation we discussed on the teleconference was to use
>> __has_include. While it is true that only a few implementations have
>> that currently, it is reasonable to expect that other implementations
>> will add it as they add support for the other macros we suggest.
>>
>> After all, 2 compilers with __has_include is better than the zero
>> compilers that define the other macros we are recommending :-)
>>
>> I am very troubled by the <cstddef> vs. <stddef.h> issue that was
>> brought up and consider that a compelling reason not to introduce
>> macros into either or both of those headers.
>>
>> John.
>>
>> _______________________________________________
>> Features mailing list
>> Features_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/features
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features
Received on 2013-06-21 01:37:39