Doc No:   SC22/WG21/N2784
                                                  PL22.16/08-0294
                                        Date:     2008-10-06
                                        Project:  JTC1.22.32
                                        Reply to: Robert Klarer
                                                  IBM Canada, Ltd.
                                                  klarer@ca.ibm.com

Minutes of WG21 Meeting, September 15-20, 2008

1. Opening activities

Clamage called the meeting to order at 09:00 (UTC-8) on Monday, September 15, 2008

1.1 Opening comments

Crowl described the arrangements and facilities for the meeting.

1.2 Introductions

Clamage had the attendees introduce themselves.

1.3 Meeting guidelines (Anti-Trust)

Clamage reviewed the patent disclosure rules.

1.4 Membership, voting rights, and procedures for the meeting

1.5 Agenda review and approval

Clamage presented the agenda (document PL22.16/08-0230 = WG21/N2720).

Motion to approve the agenda:

Approved by unanimous consent.

1.6 Distribution of position papers, WG progress reports, WG work plans for the week, and other documents that were not distributed before the meeting.

Each of the Working Group chairs presented their plans for the coming week.

Core Working Group (CWG)

Adamczyk reported that there are eleven papers in the queue of things to be discussed by CWG at this meeting. The CWG's most important task this week is to get concepts ready to be voted in, but the CWG's goal is to get all eleven papers in the queue reviewed and made the subject of formal motions.

Library Working Group (LWG)

Hinnant reported that there was an unofficial concepts meeting between meetings, and that the LWG may split into concepts and non-concepts groups for the duration of the week.

Concurrency Working Group (EWG)

Boehm reported that the EWG "... will meet with [the LWG] for a little bit in order to get the ground rules straightened out [regarding the use of multithreading in the C++ Standard Library]."

Evolution Working Group (EWG)

Crowl recalled that there were things that were explicitly deferred at the last meeting to this meeting.

Gregor asked whether there is any feasible path for those things to get into the CD at this meeting and, if not, whether the group should devote resources to them.

Plauger requested that Crowl and Glassborow quickly prioritize the EWG's work, to see whether it was likely that these items would remain unresolved by the end of the week.

1.7 Approval of the minutes of the previous meeting

Motion to approve the minutes (document PL22.16/08-0191 = WG21/N2681)

Miller proposed the following friendly amendment: "Correct the document number of the paper title "Solving the SFINAE problem for expressions." It was identified as 2658, but it should be 2634.

Klarer proposed the following friendly amendment: "Correct the spelling of Hedquist's name under agenda item 1.7."

Approved by unanimous consent as amended.

1.8 Report on the WG21 Monday meeting

1.9 Liaison reports

WG14 Liaison

Stoughton reported that WG14 is in the beginning of a revision cycle of the C standard.

Plum reported that he took a number of C++ innovations and drafted them as C extensions, including:

• static_assert
• raw strings
• utf-8 strings

Rao asked whether the C memory model will be consistent with the C++ memory model. Nelson explained that C is going to adopt the same granularity that C++ did, and Stoughton expanded on this, noting that compatibility with C++ was "a big driving factor to WG14's decisions."

POSIX Liaison

Stoughton noted that a Liaison Statement can be located on the Wiki.

1.10 Editor's report and WP approval

1.10.1 Draft WP report and approval

The most recent working paper is PL22.16/08-0233 = WG21/N2723. The Editor's Report is PL22.16/08-0234 = WG21/N2724.

Motion to accept the working paper

Approved by unanimous consent.

Hinnant indicated that N2723 has a change that Project Editor believes is editorial. Hinnant, however, believes that the change is not editorial, and he hesitates to accept N2723 because he is unsure of the procedure.

Plauger recommended approving the paper and treating the issue, if there is one, with high priority.

Becker explained that the editor's report contains information about those cases where he felt it was necessary to apply his individual discretion to the task of reflecting the committee's decisions to the existing text.

Becker also noted that the current draft is twice the length of the C++03 standard.

1.10.2 29124 Special Math Functions report and approval

Meredith reported that BSI strongly object to the organization of this paper, since it requires changes to existing standard headers, and that makes it difficult for a third party to implement a library based on this specification.

Plauger indicated that this objection can be addressed as an NB comment

The most recent working paper is PL22.16/08-0227 = WG21/N2717.

Motion to advance N2717 to ISO for Ballot

Approved by unanimous consent.

1.10.3 Decimal TR report and approval

The most recent working paper is PL22.16/08-0242 = WG21/N2732.

Motion to advance N2732 to ISO for Ballot

Approved by unanimous consent.

1.11 New business requiring actions by the committee

1.11.1 Status of TR2 (make progress or close)

Motion to close TR2

Approved by unanimous consent.

1.11.2 Status of Modules TR (make progress or close)

Motion to close Modules TR

Approved by unanimous consent.

2. Organize subgroups, establish working procedures.

We have three subgroups: Core, Library, and Evolution. There will be a subgroup of Evolution to deal with issues relating to concurrency.

The committee broke into subgroups at 10:30 (UTC-8).

3. WG sessions (Core, Library, Performance, Evolution).

4. WG sessions continue.

5. WG sessions continue.

6. WG sessions continue.

7. General session.

7.1 WG status and progress reports.

Adamczyk gave the following report on the proposals that the Core Working Group intends to move on Saturday:

Motion 1: The usual motion about issues in Ready status in the latest Core Issues list, N2714. Question about conflict between 594 and N2762.

Motion 2: N2757 "Expedited core issues handling (revision 2)", i.e., resolutions for core issues numbered 220, 592, 606, 614, 624, 681, 683, 688. Some issues we would normally move to Ready for next time, but wanted to fast-track to get into the CD.

Note that no action is being taken on the deprecated conversion of strings to char *. We're pretty sure we don't want to take away that conversion, at least because of C compatibility issues, but we have yet to decide if we want the conversion to apply only to the string kinds that were in C++2003 or to all the new string kinds. In any case, the current situation (allowed for old and some, but not all, new strings) is unacceptable.

Motion 3: N2756 "Non-static data member initializers". Note that use of "auto" for non-static data members (N2713) is dead; there are indeed technical reasons why that's a bad idea. Also, the paper being adopted adds {}-form initializers for non-static data members but doesn't change non-static data member initializers, so {}-form initializers for those would have to come later from some other paper.

Motion 4: N2764 "Forward declaration of enumerations (rev. 3)". Allows forward declaration of an enum type. This is not incomplete forward declarations as many implementations have: The forward-declared enum has a known size/base type and you can declare objects of that type; you just don't have the enumerators.

Motion 5: N2762 "Not So Trivial Issues with Trivial". Continues the POD/trivial type cleanup.

Motion 6: N2752 "Proposed Text for Bidirectional Fences". Memory model issues. Includes library changes, blessed by the LWG.

Motion 7: N2765 "User-defined Literals (aka. Extensible Literals (revision 5)". The syntax for the name of the operator functions was changed at this meeting, to operator "" xxxx() Note that the space between "" and the xxxx suffix name is required, for now. There's also some remaining desire for a way to make the operator functions once-only, so that literal value computation is not done more than once for, say, a user-defined literal in a loop. That's left as a possible future work item.

Motion 8: N2761 "Towards support for attributes in C++ (Revision 6)". The paper is ready for a vote, if not quite at the level of refinement we usually like to see. There was a significant syntax change for the position of attributes on statements just this week. There are three builtin attributes: align, noreturn, and final. An additional builtin attribute, carries_dependency, is proposed in the motion following this one.

There's some controversy about this feature:

• Pro: It allows introduction of small features without adding a keyword. These features admittedly end up somewhat as second-class citizens, but they would probably not have a chance at all if they had to get a keyword. The alignas keyword can be dropped and replaced by an attribute.
• Pro: IBM and CodeGear have already implemented something close to this proposal.
• Pro: The C committee is looking at adding the same syntax.
• Pro: In theory, having a standard syntax for attributes should allow vendors to eliminate their old vendor-specific forms and use the standard form.
• Con: It's not going to happen. Microsoft's declspec and GNU's attribute forms will doubtless be around anyway.
• Con: The syntax, using [[...]], conflicts with the syntax used by Microsoft for their (very different) attributes. Microsoft has said they will probably not implement these standard attributes.
• Con: There's controversy about whether attributes should be allowed to affect semantics. CWG is pretty clear about the fact that they can. If you think you want to restrict attributes so they can't affect semantics, you should probably vote against this proposal, because it won't be possible to stop that.
• Con: The proposal allows attributes in all kinds of places, without really saying what that means. For example, it allows attributes to apply to types, but doesn't really say how that would affect the type system. We're saved on that only because no builtin attributes that apply to types are being proposed. Vendors who add such attributes would have to define what they mean in detail.

Also note that BSI wants attributes, but doesn't want them added later if they're not in the CD. So it's sort of now or never.

Motion 9: N2782 "C++ Data-Dependency Ordering: Function Annotation". The carries_dependency attribute.

Motion 10: N2773 "Proposed Wording for Concepts (Revision 9)". Continued progress on this, but there were still some significant changes in the proposal just this week. It would be nice to have more time, but it's a marquee feature which has to be in the CD, a lot of thought has gone into it, and it's been (mostly) implemented.

Motion 11: N2782 "Named Requirements for C++0X Concepts". Syntactic sugar to make concept requirements more compact.

Motion 12: N2778 "Wording for range-based for-loop (revision 3)". The range-based for loop, including library changes (waiting for confirmation) blessed by the LWG. Requires concepts.

Motion 13: N2763 "Unified Function Syntax". Whether "auto" or "[]" should be used in the late-specified return type syntax. Lots of controversy, which is mostly about aesthetic preference, but also about

• For auto: it's a placeholder for a type, just like other uses of auto.
• For []: It's an introducer for a callable object, just like lambdas, and selecting [] gives a path forward to adding other similar callable objects, in particular local functions. (It should be noted that there was widespread agreement on both sides of the issue that if local functions are added the "[]" syntax would be good for them.)

Library Working Group

Hinnant reviewed the LWG formal motions (see below).

Future meetings:

2-6 March 2009, Summit NJ:

This meeting will be sponsored by EDG, Dinkumware, and Plum Hall, though other potential sponsors are urged to volunteer funds.

13-18 July 2009, Frankfurt Germany.

19-24 October 2009, Santa Cruz, CA area:

Plauger noted that this meeting conflicts with OOPSLA, but that there is no viable alternative except to move the meeting to the last week of October, and to ask WG14 to convene during the week of October 19.

Two members reported concern about the scheduling conflict with OOPSLA, but in a subsequent show of hands, only six members favored moving the meeting to the last week of October, while eleven members opposed such a move.

7.2 Presentation and discussion of DRs ready to be voted on. Straw votes taken.

Core Working Group

Motion 1. Move we apply the resolutions of all issues marked "ready" from N2714 to the C++0X Working Paper, i.e. issues numbered 222, 594, 634, 637, 639, 647, 648, 649, 651, 659, 660, 671, 677, 679, 686.

Approved by unanimous consent.

Motion 2. Move WG21/N2757 "Expedited core issues handling (revision 2)" into the C++0X Working Paper, i.e. resolutions for core issues numbered 220, 592, 606, 614, 624, 681, 683, 688.

Approved by unanimous consent.

Motion 3. Move WG21/N2756 "Non-static data member initializers" into the C++0X Working Paper.

Nelson inquired as to whether this item had been implemented. Caves replied, explaining that it had not.

Motion 4. Move WG21/N2764 "Forward declaration of enumerations (rev. 3)" into the C++0X Working Paper.

Approved by unanimous consent.

Motion 5. Move WG21/N2762 "Not So Trivial Issues with Trivial" into the C++0X Working Paper.

Approved by unanimous consent.

Motion 6. Move WG21/N2752 "Proposed Text for Bidirectional Fences" into the C++0X Working Paper.

Approved by unanimous consent.

Motion 7. Move WG21/N2765 User-defined Literals (aka. Extensible Literals (revision 5) into the C++0X Working Paper.

Merrill asked what happened to the suggestion to change the declaration syntax to use "operator for." Vandevoorde replied that there was no significant support for that idea.

Stoughton asked whether has this item been implemented. Adamczyk explained that it had not.

Motion 8. Move WG21/N2761 "Towards support for attributes in C++ (Revision 6)" into the C++0X Working Paper.

Abrahams asked "how do we ensure that vendors use the same attribute names for the same functionality?"

Adamczyk explained that "there is a facility for qualifying attribute names, but apart from that, market pressures will encourage convergence."

Meredith asked whether he, as a vendor, is allowed to do things with an attribute that I am not allowed to with a pragma.

Adamczyk answered that the syntax for usage is more selective than for pragmas.

Vandevoorde stated that this feature creates an opportunity for future language evolution, as the standard committee can add portable attributes in the future.

Dawes asked whether he will be, for example, forced to use to conditional compilation in BOOST code.

Merrill observed that code that requires vendor-specific extensions will always require conditional compilation for portability, regardless of whether or not attributes are used.

Witt agreed, arguing that attributes are no worse than the status quo, since the situation with #pragmas is the same.

Stroustrup asked whether it is true that a program is ill-formed if it uses a pragma that is ignored by the compiler.

Adamczyk explained that the implementation is free to specify that it ignores attributes that it doesn't understand.

Spertus asked whether it is true that Microsoft refuses to implement this feature. Caves confirmed that it is.

Discussion ensued.

Glassborow noted that just about every major compiler already has attributes, and further opined "It's time we standardized the syntax for them."

Motion 9.

Approved by unanimous consent.

Motion 10.

Motion 11. Move WG21/N2780 "Named Requirements for C++0X Concepts" into the C++0X Working Paper.

Motion 12. Move WG21/N2778 "Wording for range-based for-loop (revision 3)" into the C++0X Working Paper.

Nelson asked whether this proposal has been implemented. Gregor confirmed that it had.

Abrahams asked, for his information, why Vandevoorde was consistently voting against Concepts-related motions.

Vandevoorde explained that he does not have enough confidence in the quality of the core Concepts specification, and the risk of getting it wrong is too great.

Motion 13. Move WG21/N2763 "Unified Function Syntax" into the C++0X Working Paper.

Adamczyk recalled that, when lambda was voted into the WP, it was with the understanding that it would not prejudice the committee toward "auto" instead of "[]" Further, Adamczyk reported that this proposal does not completely resolve all of the grammar changes required to enable []. The [] is a placeholder for a type, rather than an introducer. The grammar can later be modified to allow [] to act as an introducer.

Discussion ensued.

Glassborow reported that, assuming this motion is approved, the UK will be issuing an NB comment that they want [] to be an introducer rather than a placeholder for a type.

Discussion ensued.

Stroustrup reported that France will support the UK position on the use of brackets.

Caves suggested that the committee trying to create unity by using a notation that is different from what almost all programmers use today; that is confusing and unnecessary

Marcus expressed a preference that, when things are similar but not exactly the same, they should not look the same, to emphasize the distinction.

Merrill noted that this is a very large change in how people write C++, and that large projects will transition to any new notation gradually, so both forms will be evident in a single source tree.

Vandevoorde argued that the keyword "auto" is counter-intuitive, as there is nothing in the word auto that implies "placeholder."

Merrill agreed, but explained that auto looks like a specifier.

Spicer asked whether the bracket syntax introduces an ambiguity.

Adamczyk speculated that an ambiguity may arise once the grammar is modified to make the square brackets an introducer, just as implicit int created ambiguities.

Crowl expanded on this, noting that the ambiguity doesn't arise when the function has a late-specified return type.

Gibbons predicted that programmers will be tempted to define a macro like #define Function(name) []name.

Crowl observed that the difference in semantics that have been highlighted are not so much differences as restrictions. For example, there are no default parameters for lambdas because it makes no sense to allow defaults for parameters that you can't be named anyway. "It's not so much that functions and lambdas are inconsistent, but that different constraints apply."

Plauger, noting that there appears to be no consensus, asked whether there is some state that in which the committee can leave the draft in that will appease all sides of the debate.

Spicer suggested that "perhaps we could agree that this is something that we can continue to work on."

Plauger agreed that "this is unequivocally an open issue and the failure to reach consensus today should not prejudice the committee against any [future] proposal" that aims to solve the problem.

Library Working Group

Motion 1. Move we apply the resolutions to the following issues from N2727 to the C++0X Working Paper: 180, 387, 396, 522, 629, 691, 713, 714, 720, 728, 762, 769, 771, 772, 776, 779, 787, 805, 806, 807, 808, 809, 813, 824, 829, 842, 844, 848, 850, 852

Vandevoorde asked whether any of the issues in this list deal with Concepts. Hinnant: "No."

Approved by unanimous consent.

Motion 2. Move we apply the resolutions to the following issues to the C++0X Working Paper: 23, 675, 692, 698, 709, 734, 804, 820, 823 (requires foundational concepts), 843, 856 These issues were not in Ready status in the pre-meeting mailing. However the LWG reviewed them and believes they should be go into the WP at this meeting because they are critical to the quality of the CD.

Motion 3. Move we apply N2771 LWG Issues" to the C++0x working paper. 858, 882

Approved by unanimous consent.

Motion 4. Move we apply N2783 "Collected Issues with Atomics" to the C++0x working paper. 818, 845, 846, 864

Approved by unanimous consent.

Motion 5. Move we apply N2637 "Revisiting std::shared_ptr comparison" to the C++0X Working Paper.

Meredith recalled that this was controversial at the previous meeting, but that he has withdrawn his objections.

Motion 6. Move we apply N2755 "Concepts for the C++0x Standard Library: Chapter 17 -Introduction (Revision 2)" to the C++0X Working Paper.

Motion 7. Move we apply N2774 "Foundational Concepts (Revision 5)" to the C++0X Working Paper.

Motion 8. Move we apply N2777 "Concepts for the C++0x Standard Library: Iterators (Revision 4)" to the C++0X Working Paper.

Motion 9. Move we apply N2758 "Iterator Concepts for the C++0x Standard Library (Revision 6)" to the C++0X Working Paper.

Motion 10. Move we apply N2759 "Concepts for the C++0x Standard Library: Algorithms (Revision 6)" to the C++0X Working Paper.

Motion 11. Move we apply N2768 "Allocator Concepts, part 1 (revision 2)" to the C++0X Working Paper.

Motion 12. Move we apply N2770 "Concepts for the C++0x Standard Library: Utilities (Revision 6)" to the C++0X Working Paper.

Motion 13. Move we apply N2620 "Concepts for the C++0x Standard Library: Diagnostics Library" to the C++0X Working Paper.

Motion 14. Move we apply N2776 "Concepts for the C++0x Standard Library: Containers (Revision 4)" to the C++0X Working Paper.

Motion 15. Move we apply only the changes for section 26.6 in the paper N2736 "Concepts for the C++0x Standard Library: Numerics (Revision 4)" to the C++0X Working Paper.

Motion 16. Move we apply N2779 "Concepts for clause 18 (Part 2)" to the C++0X Working Paper.

Motion 17. Move we apply N2668 "Concurrency Modifications to Basic String" to the C++0X Working Paper.

Approved by unanimous consent.

Motion 18. Move we apply N2748 "Strong Compare and Exchange" to the C++0X Working Paper.

Approved by unanimous consent.

Motion 19. Move we apply N2760 "Input/Output Library Thread Safety" to the C++0X Working Paper.

Dawes explained that this paper was not in the pre-meeting mailing, but the LWG felt this was non-controversial and that it is required for the completeness of the CD.

Halpern asked whether this proposal has been implemented. Plauger explained that this proposal seeks to codify existing practice, so it has been implemented broadly.

Approved by unanimous consent.

Motion 20. Move we apply N2769 "Detailed Reporting for Input/Output Library Errors (Revision 2)" to the C++0X Working Paper.

Motion 21. Move we apply N2772 "Variadic Functions: Variadic Templates or Initializer Lists? (revision 1)" to the C++0X Working Paper.

Approved by unanimous consent.

Motion 22. Move we apply N2775 "Small library thread-safety revisions" to the C++0X Working Paper.

Approved by unanimous consent.

Motion 23. Move we apply N2671 "An Asynchronous Future Value" with the name for the error category changed from "FUTURE" to "future" to the C++0X Working Paper.

Motion 24. Move we apply N2709 "Packaging Tasks for Asynchronous Execution" with the addition that it goes into the same section and header file as futures to the C++0X Working Paper.

Motion 25. Move we apply N2786 "Simplifying unique_copy (Revision 1)" to the C++0X Working Paper.

Motion 26. Move we apply N2530 "Making It Easier to Use std::type_info as an Index" to the C++0x working paper.

Meredith expressed his belief that a concepts constraints library there will enable better techniques for achieving the same end.

Approved by unanimous consent.

Motion to move the Working Draft to Committee Draft Status

Move we empower the Convenor to advance the Working Paper as amended by the foregoing motions to Committee Draft Status.

A review committee was appointed to assist the Project Editor. This committee consists of:

• Adamczyk
• Hinnant
• Dawes
• Miller
• Gregor
• Meredith
• Crowl
• Brown
• Widman

8. WG sessions continue

9. WG sessions continue

10. Review of the meeting

10.1 Formal motions, including DRs to be resolved.

Clamage reviewed all of the motions that were the subject of straw polls under Agenda Item 7, with the exception of CWG Motion 13, on Unified Function Syntax.

No objection was raised against any of the motions.

10.2 Future meetings:

See 11.1, below.

10.3 Issues delayed until Saturday

None.

11. Plans for the future

11.1 Next meeting

Adamczyk requested that members inform him about their plans to attend the Summit NJ meeting.

Maurer reported that the POSIX C++ bindings group will be meeting on the Friday before the WG21 meeting in Frankfurt.

Maurer also reported that there will be tours on the Saturday and Sunday preceding the WG21 meeting, and requested that members inform him about their plans to participate.

11.2 Mailings

Nelson reported the following mailing deadlines:

post-meeting mailing	Oct 3, 2008
mid-term mailing	December 5, 2008
pre-Summit mailing	February 26, 2009

11.3 Following meetings

The following meetings are as follows:

1. March 2009, Summit NJ
2. July 2009, Frankfurt Germany
3. October 2009, Santa Cruz CA

Plum moved to thank the host. Applause.

Brown moved to thank the outgoing convenor. Applause.

There was general agreement that new versions of the core and library issues lists would not appear in the mid-meeting mailing.

Motion to adjourn

Unanimous consent.

Attendance