C++ Logo

sg10

Advanced search

Re: [SG10] On __has_attribute

From: Richard Smith <richard_at_[hidden]>
Date: Wed, 26 Mar 2014 13:31:45 -0700
On Wed, Mar 26, 2014 at 10:58 AM, Nelson, Clark <clark.nelson_at_[hidden]>wrote:

> > > An implementation should only claim to support an attribute-token with
> no
> > > attribute-namespace if it follows the behavior specified by a draft of
> the
> > > C++ standard or of a technical specification produced by ISO/IEC
> > > JTC1/SC22/WG21. An implementation should only claim to support an
> > > attribute-token with an attribute-namespace if it follows the behavior
> > > specified by the vendor identified by the attribute-namespace.
>
> > > [OPEN QUESTION: Do we want to provide recommendations like this last
> > > paragraph at all? If so, should we list the currently-know
> > > attribute-namespaces? Having a centralized list of them is useful, and
> this
> > > seems like a good place to maintain that list. Would it be in-scope
> for the
> > > features SG to maintain a list of the known vendor extension
> attributes?]
>
> > I don't think the last paragraph is needed, not that I'd object if
> someone
> > really wanted it.
>
> To me, this seems so obvious that I would really hope we wouldn't have to
> say it.


So far, this sounds like consensus for dropping that paragraph. (I'm fine
with that, by the way.)

> I don't think maintaining a list of known vendor extension attributes is
> in
> > the charter of SG10. If one were maintained, would it be just the
> names,
> > the names and the syntax, or the names, syntax, and semantics?
>
> I agree with John: we don't want to keep track of all the vendor extension
> attributes. But I think it would be great if we could maintain a table that
> correlated attribute-namespace names with URLs at which vendors document
> their list of extended attributes. (Assuming, of course, that vendors
> actually use attribute-namespaces.)


I like the idea of this table. Do you think this should be included in our
standing document, or hosted elsewhere on isocpp.org, or somewhere else? I
think a separate page on isocpp.org would probably be appropriate.

Received on 2014-03-26 21:31:46