On 01/01/2015 09:31 PM, Richard Smith wrote:
> On Mon, Dec 29, 2014 at 5:45 PM, Nelson, Clark <clark.nelson_at_[hidden]
> <mailto:clark.nelson_at_[hidden]>> wrote:
>
> I notice that Richard is behind quite a few of the new features,
> for almost
> none of which is any feature-test macro mentioned in the document.
> [shaking
> head] Richard, Richard. :-)
>
>
> It's official, I'm a terrible person. Apologies.
>
> On Tue, Dec 30, 2014 at 9:54 AM, Nelson, Clark
> <clark.nelson_at_[hidden] <mailto:clark.nelson_at_[hidden]>> wrote:
>
> > For N3928 Extending static_assert why not just bump up the date on __cpp_static_assert?
>
> Yeah, that's definitely worth considering. The change is a pretty
> minor
> tweak. (The recommendations I included for this were the ones provided
> in N3928 -- thanks, Walter.)
>
>
> Strongly agreed. This is a poster child for why we have version
> numbers on our feature macros.
>
> > We could bump the date on __cpp_unicode_literals for - Scartch that - that's for strings.
> > Just __cpp_utf8_char_literals I think.
>
> Noted, thanks.
>
>
> I don't think we need or want a new macro name here. If I had a time
> machine, I'd say:
>
> __cpp_unicode_literals == 200704 means "unicode character literals"
> __cpp_unicode_literals == 200710 means "unicode character and string
> literals"
> __cpp_unicode_literals == 201411 means "unicode character and string
> literals including u8 char literals"

I like this idea a lot.
We could implement this and just have
__cpp_unicode_literals == 200704
be synonymous with
|__cpp_unicode_characters|== 200704
The column in the SD-6 document would just have both both options
listed. We could put in a note to that effect.
It seems ironic that our feature testing system has issues bit I guess
it's to be expected. ;-)

Alternatively we could have:

|__cpp_unicode_characters|== 200704 means "unicode character literals
u'a' and U'a'"
__cpp_unicode_literals == 200710 means unicode string literals u"", U"",
u8""
Then go back to |__cpp_unicode_characters| with
|__cpp_unicode_characters|== 201411 means "unicode character literals
u'a' and U'a' and u8'a'"
This would separate character literals and string literals (as we have
already started) but we wouldn't have a feature with two synonymous
macros. And it's logically defensible too.

We would not be adding a new macro in either case.
>
> This slightly changes a previously-published recommendation, in that
> simply testing whether __cpp_unicode_literals is defined would no
> longer suffice to detect unicode string literal support, so I'm happy
> to drop the first line. (I don't expect any vendor will ever ship an
> implementation that sets __cpp_unicode_literals to 200704, so it seems
> academic, and I'm not too worried about including it.)
>
> > N4295 - Folding expressions: __cpp_parameter_pack_sorcery,
> __cpp_fold_expressions is probably better.
>
> Interesting. Richard, for my curiosity, can you explain why the
> title of
> the document doesn't match the terminology used in the document?
>
>
> The paper had its name before we had decided on the name of the
> grammar term and the heading of the subclause in the standard. In the
> title, "folding" is being used as a verb rather than an adjective
> (think "a paper on folding expressions over an arbitrary binary
> operator"). The feature is called "fold expressions" within the
> standard text; I think __cpp_fold_expressions is the best name here.
>
> (If I had my time machine, I'd probably remove the "ing" from the
> title, at least in the wording paper, for clarity.)
>
> > N4266 - Attributes for namespaces and enumerators. They really
> are sort of two different things:
>
> > __cpp_namespace_attributes 201411
> > __cpp_enumerator_attributes 201411
>
> Hmm. It could be argued that each attribute that can appertain to a
> namespace or enumerator is a distinct thing. Today there is only
> one such
> attribute: deprecated. We could even consider bumping the value of
> __cpp_has_attribute(deprecated).
>
>
> I like both new macros. I don't think we need to change the value of
> __cpp_has_attribute(deprecated) unless we're worried that an
> implementation might ship the syntax support for namespace attributes
> and enumerator attributes but not allow the [[deprecated]] attribute
> to appertain to them.
>
> OK. I have another question about this one. It mentions that the new
> declarations are available by including any of an even dozen
> headers. Does
> that mean that our recommendations should specify this macro as being
> defined by all of those headers?
>
>
> Yes, I think so. I would imagine every implementation does this in
> practice by using a helper header, so I think we'd be frustrating both
> our users and our implementors if we didn't make the provision of
> macros and declarations line up.
>
>
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features