[SG10] Updates to SD-6

Ed Smith-Rowland 3dw4rd at verizon.net
Fri Jan 2 18:24:23 CET 2015


On 01/01/2015 09:31 PM, Richard Smith wrote:
> On Mon, Dec 29, 2014 at 5:45 PM, Nelson, Clark <clark.nelson at intel.com 
> <mailto:clark.nelson at intel.com>> 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 intel.com <mailto:clark.nelson at intel.com>> 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 isocpp.open-std.org
> http://www.open-std.org/mailman/listinfo/features

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/features/attachments/20150102/b46c4fe4/attachment.html 


More information about the Features mailing list