Doc No:   SC22/WG21/N2355
                                                  J16/07-0215
                                        Date:     2007-07-20
                                        Project:  JTC1.22.32
                                        Reply to: Robert Klarer
                                                  IBM Canada, Ltd.
                                                  klarer@ca.ibm.com

Minutes of J16 Meeting No. 45/WG21 Meeting No. 40, July 16-20, 2007

1. Opening activities

Clamage called the meeting to order at 09:10 (GMT) on Monday, July 16, 2007

1.1 Opening comments

Klarer 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

Nelson reviewed membership rules. Nelson then circulated the attendance list and membership list. Clamage reviewed voting rules and reviewed procedures for the meeting.

1.5 Agenda review and approval

Clamage presented the agenda (document J16/07-0061 = WG21/N2269).

Motion to approve the agenda:

Clamage proposed that the agenda be amended by delaying liaison reports until Thursday.

Motion as amended:

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 CWG made good progress at the ad hoc meeting on Concepts in New Jersey in June.

Adamczyk also expressed a desire to schedule some committee time for a discussion of the problem relating to the interaction of overload resolution with decltype and other, similar language features.

Library Working Group (LWG)

Hinnant reported that the LWG has 27 new papers to review. In addition, the LWG has 168 open issues, 9 of them in ready state.

Evolution Working Group (EWG)

Stroustrup reported that he intends to dissolve the EWG as soon as possible, but that the threads group should keep working until they are done.

The EWG will decide today which papers it must discuss as a group, and that decision will determine whether EWG will be dissolved before the end of the week.

1.7 Approval of the minutes of the previous meeting

Motion to approve the minutes (document J16/06-0179 = WG21/N2110)

Klarer proposed that the minutes be approved with one amendment: list National ICT Australia is listed as a voting member, not an attending member.

Accept the minutes as amended

1.8 Report on the WG21 Sunday meeting

Sutter reports:

• five countries are represented at this meeting; all five have voting status
• the ISO secretariat is still in the process of publishing TR1
• a ballot on a NWI on Special Math Functions is in progress
• the next SC22 plenary is in Singapore in September
• the drafting committee will be composed of Adamczyk, Dos Reis, and Hinnant

1.9 Liaison reports

WG14 Liaison

Deferred until Thursday.

1.10 Editor's report and WP approval

The current draft of the WP is J16/07-0175 = WG21/N2315.

Motion to accept the working paper

1.11 New business requiring actions by the committee

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 (GMT).

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

4. WG sessions continue.

5. WG sessions continue.

6. WG sessions continue.

7. General session.

C Committee

Plauger reports: WG14 last met in London, during the week of April 23, 2007. There was a strong sense at that meeting that the C standard will be revised, and there was discussion of what kind of areas would be covered in such a revision. WG14 will follow WG21's lead on specific technical areas, especially concurrency.

POSIX

Stoughton reported on a meeting that was held on July 15, 2007, in which plans were made to specify a thin binding of C++ to POSIX. There were 19 attendees in total at this meeting, including 3 core members from the Austin Group. It was agreed that a WG will be formed to develop a new standard within the IEEE. This standard will specify no extensions to the C++ core language. Instead is will specify only libraries. The intention is that a "POSIX++" standard will be delivered in 2011.

7.1 WG status and progress reports.

Core Working Group

Adamczyk presented Core Working Group status and reviewed formal motions to be made Friday (for formal motions, see 9.1, below).

Adamczyk's status report is quoted below:

1. We discussed decltype, generalized constant expressions, POD definition, defaulted/deleted functions, __func__, alignment, strongly-typed enums, concepts, new syntax for function return type, nullptr, initializer lists, and explicit conversion functions.
2. Note that the alignment proposal intends to outlaw non-power-of-two alignments. We don't know of any architectures that would affect.
3. We spent a lot of time discussing the Core issue 339 problem:
   
   The problem is whether arbitrary expressions (for example, ones that include overload resolution) are allowed in template deduction contexts, and, if so, which expression errors are SFINAE failures and which are hard errors.
   
   Core issue 339 deals with arbitrary expressions inside sizeof in deduction contexts. That's a fringe case right now (most compilers don't accept them). decltype makes the problem worse, because the standard use case is one that involves overload resolution. Generalized constant expressions make it worse yet, because they allow overload resolution and class types to show up in any constant expression in a deduction context.
   
   Why is this an issue? Why don't we just say everything is allowed and be done with it?
   
   First, because it's hard to implement the general case. Template deduction/substitution has historically used a simplified model of semantic checking, i.e., the SFINAE rules (which are mostly about types), instead of full semantic checking. This limited semantic checking is typically done by completely separate code from the code for "normal" expression checking, and it's not easy to extend it to the general case. "Speculative compilation" sounds like an easy way out, but in practice compilers can't do that. Second, because it affects name mangling and therefore the ABI. Third, because we need to figure out what to say and how to say it in the standard. At the Oxford meeting, we were headed toward a solution that imposed a restriction on expressions in deduction contexts, but such a restriction seems to really hamper uses of constexpr functions. So we're now proposing that fully general expressions be allowed, and that most errors in such expressions be treated as SFINAE failures rather than errors.
   
   One issue with writing standards wording for that is how to define "most". There's a continuum of errors, some errors being clearly SFINAE failures, and some clearly "real" errors, with lots of unclear cases in between. We decided it's easier to write the definition by listing the errors that are not treated as SFINAE failures, and the list we came up with is as follows:
   
   errors that occur while processing some entity external to the expression, e.g., an instantiation of a template or the generation of the definition of an implicitly-declared copy constructor errors due to implementation limits errors due to access violations (this is a judgment call, but the philosophy of access has always been that it doesn't affect visibility) Everything else produces a SFINAE failure rather than a hard error.
   
   There was broad consensus that this felt like a good solution, but that feeling was mixed with trepidation on several fronts:
   
   The implementation cost is quite significant, at least for EDG and Microsoft (under GCC, it may be easier). It involves moving around a large amount of code. This may delay implementation and introduce bugs in compilers. While it seems upward compatible with C++03, it's possible it will break existing code. Any big change in template processing has a pretty good chance of breaking something. Since there is no implementation, we don't really know how it will work in the real world.
   
   We will be producing Working Draft wording for this proposal for the Kona meeting, but there will probably not be an implementation anytime soon.
   
   So, how to proceed with decltype and generalized constant expressions? Do we wait until the wording for a resolution to Core issue 339 is prepared and approved, or do we vote them in and trust that we will resolve this problem before the standard is issued? To some extent, those papers are orthogonal to this issue, but it's also true that decltype is essentially unusable until a solution to this problem is implemented.
   
   We decided the full committee should get to decide.

Dos Reis explained that none of the motivating examples in the constexpr paper is affected by the problem that is reported in issue 339.

Stroustrup asked Dos Reis whether the existing partial implementation of the constexpr proposal handles all of the use cases that appear in the corresponding library paper. Dos Reis confirmed that is does.

Nelson asked what part of the proposal is not yet implemented, and Dos Reis replied that it was the deduction case.

Hinnant asked whether result_of's use of decltype runs afoul of 339. Gregor explained that it does not, because result_of is a non-deduction context.

Discussion ensued.

Gregor asked whether constant folding requires full interpretation of C++ expressions, including function calls and template instantiation? Dos Reis replied that it does not, as there are limits on what can constitute a constant expression. Recursive functions, for example, cannot be constexpr. The only complication is overload resolution.

Spicer elaborated on Dos Reis, response, noting that constant folding involves function calls, constructor calls, and member accesses. Before this, folding involved simple arithmetic expressions. It is now far more complicated than that.

Motion 1. Move all issues in Ready status in J16/07-0164=WG21/N2304 to DR status and into the Working Draft. There is only one such issue, number 452.

Unanimous consent.

Motion 2. Adopt J16/07-0095=WG21/N2235, "Generalized Constant Expressions -- Revision 5".

Straw Poll: support for Motion 2

Motion 3. Adopt J16/07-0203=WG21/N2343, "Decltype(revision 7): proposed wording".

Straw Poll: support for Motion 3

Motion 4. Adopt J16/07-0200=WG21/N2340, "C99 Compatibility: __func__ and predeclared identifiers (revision 2)".

Unanimous consent.

Motion 5. Adopt J16/07-0202=WG21/N2342, "POD's Revisited; Resolving Core Issue 568 (Revision 5)".

Straw Poll: support for Motion 5

Motion 6. Adopt J16/07-0201=WG21/N2341, "Adding Alignment Support to the C++ Programming Language/Wording".

Straw Poll: support for Motion 6

Motion 7. Adopt J16/07-0207=WG21/N2347, "Strongly Typed Enums (revision 3)".

Straw Poll: support for Motion 7

Motion 8. Adopt J16/07-0206=WG21/N2346, "Defaulted and Deleted Functions".

Straw Poll: support for Motion 8

Library Working Group

Hinnant presented Library Working Group status and reviewed formal motions to be made Friday (for formal motions, see 9.1, below).

Motion 1. Move Ready issues into C++0X Working Paper:

• 644 Possible typos in 'function' description
• 551 <ccomplex>
• 531 array forms of unformatted input functions
• 566 array forms of unformatted input function undefined for zero-element arrays
• 640 27.6.2.5.2 does not handle (unsigned) long long
• 643 Impossible "as if" clauses
• 628 Inconsistent definition of basic_regex constructor
• 646 const incorrect match_result members
• 604 Decimal: Storing a reference to a facet unsafe.

Unanimous consent.

• 604 Decimal: Storing a reference to a facet unsafe.

Unanimous consent.

Motion 2. Move N2345 "Placement Insert for Containers (Revision 2)" into the C++0x Working Paper.

Straw Poll: support for Motion 2

Motion 3. Move N2194 "decltype for the C++0x Standard Library" into the C++0X Working Paper.

Straw Poll: support for Motion 3

Motion 4. Move N2292 "Standard Library Applications for Deleted Functions" into the C++0x Working Paper.

Straw Poll: support for Motion 4

Motion 5. Move N2293 "Standard Library Applications for Explicit Conversion Operators" into the C++0x Working Paper.

Not moved because the corresponding core language changes will not be adopted at this meeting.

Motion 6. Move N2349 "Constant Expressions in the Standard Library -- Rivision 2" into the C++0X Working Paper.

Nelson asked whether this proposal depends on any of the parts of constexpr that are affected by core issue 339? Dos Reis explained that it does not.

Straw Poll: support for Motion 6

Motion 7. Move N2348 "Wording for std::numeric_limits<T>::lowest()" into the C++0X Working Paper.

Straw Poll: support for Motion 7

Motion 8. Move N2350 "Container insert/erase and iterator constness (Revision 1)" into the C++0X Working Paper.

Hinnant explaied that the LWG extended the paper at this meeting to modify the splice member function, in addition to insert and erase, and invited any member who felt that the change was too new to be the subject of a vote to speak up.

Plauger reported that this has been implemented, and it caused no problems with existing conformance buckets.

Unanimous consent.

Motion 9. Move N2351: "Improving shared_ptr for C++0x Standard Library, Revision 2" into the C++0X Working Paper.

Unanimous consent.

Motion 10. Move N2299 "Concatenating tuples" into the C++0x Working Paper, except change the name of the four functions named concatenate to tuple_cat.

Straw Poll: support for Motion 10

Motion 11. Move N2007 "PROPOSED LIBRARY ADDITIONS FOR CODE CONVERSION" into the C++0x Working Paper.

Unanimous consent.

Motion 12. Move N2308 "Adding allocator support to std:function for C++0x" into the C++0x Working Paper, except change the pass-by-value Allocator argument to pass-by-const-reference.

Straw Poll: support for Motion 12

Motion 13. Move N2321 "Enhancing the time_get facet for POSIX(R) compatibility, Revision 2" into the C++0X Working Paper.

Goldthwaite asked whether this change will break binary compatibility. Plauger confirmed that it will, and that is why LWG prefers to put this into 0x rather than TR2

Unanimous consent.

Motion 14. Move N2353 "A specification for vector<bool>" into the C++0X Working Paper.

Unanimous consent.

Motion 15. Move N2179 "Language Support for Transporting Exceptions between Threads" into the C++0X Working Paper.

Straw Poll: support for Motion 15

Evolution Working Group

Evolution Working Group (EWG) will be making no formal motions Friday.

Stroustrup reported on EWG status. In particular, Stroustrup explained that there are two proposals that EWG has decided not to move on unless there are specific demands that they be revisited:

• explicit overrides
• namespace regions

Stroustrup went on to report that, if these items either pass or stay dormant, then EWG will have only one item to work on in Kona: lambdas.

Nelson asked about the status of dynamic linking. Crowl indicated that it is his intention to continue to work on this item, though it is not likely to make enough progress to arrive in time.

Concurrency Group

The Concurrency Group will be making no formal motions Friday.

Future meetings:

See 10.1, below.

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

8. WG sessions continue

9. Review of the meeting

9.1 Formal motions, including DRs to be resolved.

Core Working Group Motions

Motion 1. Move all issues in Ready status in J16/07-0164=WG21/N2304 to DR status and into the Working Draft. There is only one such issue, number 452.

Unanimous consent.

Motion 2. Adopt J16/07-0095=WG21/N2235, "Generalized Constant Expressions -- Revision 5".

Gregor indicated that this feature looked to him to be difficult and costly to implement, and that he was compelled to vote no to this motion. "I really need to see an implementation."

Support for Motion 2:

Motion 3. Adopt J16/07-0203=WG21/N2343, "Decltype(revision 7): proposed wording".

Support for Motion 3:

Motion 4. Adopt J16/07-0200=WG21/N2340, "C99 Compatibility: __func__ and predeclared identifiers (revision 2)".

Unanimous consent.

Motion 5. Adopt J16/07-0202=WG21/N2342, "POD's Revisited; Resolving Core Issue 568 (Revision 5)".

Unanimous consent.

Motion 6. Adopt J16/07-0201=WG21/N2341, "Adding Alignment Support to the C++ Programming Language/Wording".

Adamczyk reported that there had been a concern -- expressed overnight by email -- about whether certain alignments can be supported by this proposal. Adamczyk suggested that this concern can be addressed as a CWG issue.

Unanimous consent.

Motion 7. Adopt J16/07-0207=WG21/N2347, "Strongly Typed Enums (revision 3)".

Support for Motion 7:

Motion 8. Adopt J16/07-0206=WG21/N2346, "Defaulted and Deleted Functions".

Support for Motion 8:

LWG Motions

Motion 1. Move the following LWG issues into C++0X Working Paper:

• 644 Possible typos in 'function' description
• 551 <ccomplex>
• 531 array forms of unformatted input functions
• 566 array forms of unformatted input function undefined for zero-element arrays
• 640 27.6.2.5.2 does not handle (unsigned) long long
• 643 Impossible "as if" clauses
• 628 Inconsistent definition of basic_regex constructor
• 646 const incorrect match_result members

Unanimous consent.

• 604 Decimal: Storing a reference to a facet unsafe.

Support for Motion 2:

Motion 3. Move N2345 "Placement Insert for Containers (Revision 2)" into the C++0x Working Paper.

Unanimous consent.

Motion 4. Move N2194 "decltype for the C++0x Standard Library" into the C++0X Working Paper.

Unanimous consent.

Motion 5. Move N2292 "Standard Library Applications for Deleted Functions" into the C++0x Working Paper.

Support for Motion 5:

Motion 6. Move N2293 "Standard Library Applications for Explicit Conversion Operators" into the C++0x Working Paper.

Not moved because the corresponding core language changes will not be adopted at this meeting.

Motion 7. Move N2349 "Constant Expressions in the Standard Library -- Rivision 2" into the C++0X Working Paper.

Support for Motion 7:

Motion 8. Move N2348 "Wording for std::numeric_limits<T>::lowest()" into the C++0X Working Paper.

Unanimous consent.

Motion 9. Move N2350 "Container insert/erase and iterator constness (Revision 1)" into the C++0X Working Paper.

Unanimous consent.

Motion 10. Move N2351: "Improving shared_ptr for C++0x Standard Library, Revision 2" into the C++0X Working Paper.

Support for Motion 10:

Motion 11. Move N2299 "Concatenating tuples" into the C++0x Working Paper, except change the name of the four functions named concatenate to tuple_cat.

Support for Motion 11:

Motion 12. Move N2007 "PROPOSED LIBRARY ADDITIONS FOR CODE CONVERSION" into the C++0x Working Paper.

Unanimous consent.

Motion 13. Move N2308 "Adding allocator support to std:function for C++0x" into the C++0x Working Paper, except change the pass-by-value Allocator argument to pass-by-const-reference.

Unanimous consent.

Motion 14. Move N2321 "Enhancing the time_get facet for POSIX(R) compatibility, Revision 2" into the C++0X Working Paper.

Unanimous consent.

Motion 15. Move N2353 "A specification for vector<bool>" into the C++0X Working Paper.

Unanimous consent.

Motion 16. Move N2179 "Language Support for Transporting Exceptions between Threads" into the C++0X Working Paper.

Seymour asked whether this proposal makes sense in the absence of threads from the language. Hinnant replied that it does, as it allows a user to store an exception that has been caught in an ellipsis handler.

Unanimous consent.

Hinnant announced that LWG is going to have a winter meeting in Bloomington Indiana in late January or early February to discuss concepts.

As instructed by the LWG, Hinnant then delivered the following message from the LWG to the full committee:

• By the end of Kona, we (the LWG) do not feel we can responsibly evaluate thread pools and futures.
• The use of concepts in the library is essential for the success of C++0x.
• By the end of Kona we (the LWG) do not feel we can responsibly evaluate concepts for the library.

Suggesting that "the emperor has no FCD, at least not in Kona," Sutter proposed that the committee's goal for Kona should be to ship a CD, but not an FCD, in effect reverting to the "work completed in Fall 2009" timeline that Sutter proposed in Portland. This revised plan gives National Bodies more than one chance to submit comments, and results in the nice regular cadence of releasing a document each fall until 2009. Sutter did note, though, that there is extra work for the committee if a CD is issued: CD comments will have to be resolved.

Glassborow noted that ISO has rules that preclude the discussion of documents that are currently at ballot, and that shipping a CD at Kona would mean that the committee would not be able to discuss the standard for several months after the ballot had been issued. Sutter replied that Stoughton had assured him that POSIX documents were regularly going out and being processed quickly. Based on this experience, Sutter believes that the ballot periods can be limited to three months (i.e. the intervals between meetings).

Plauger cautioned the group that nothing new should be added to the schedule of work just because the committee has more time. Furthermore, he indicated that he cannot approve Sutter's proposed change to the project schedule unless the Project Editor can handle the extra workload. Becker responded by indicating that the amount of work that this creates for the project editor depends on the quality of the proposed changes to the WD that are submitted to him.

Discussion ensued.

Nelson observed that there is no decision that the committee can formally make today, and that this is all food for thought about what the committee will do in Kona, but the question to ask in Kona is: will we be willing to issue for comment a document that does not have all of the features that WG21 intends to include in the IS?

Stroustrup stated that the only way to hit the committee's target of a 2009 IS is to slip only one meeting, and that will not be enough. He felt that the committee will have something to release in Kona that is good enough to start soliciting comments.

Spertus asked whether it was possible to issue a CD that omits library support for concepts, for example. Sutter explained that CDs are known to be incomplete, because they are not Final CDs.

Spertus expressed a desire to solicit comments on the library changes for concepts. Sutter replied that there will be an FCD cycle that will give the committee the opportunity to receive those comments. Sutter expects that the CD will contain placeholders for features that are "missing," much as the Registration Document has. Seymour noted that a comment to the effect that a feature is missing from the CD is easy to answer: "OK, see the placeholder; we'll add that feature."

Miller asked, given the concern for the duration of the vote for the CD, whether it is possible to make the spring meeting as late as possible, effectively making the interval between meetings longer. Sutter indicated that he would continue to explore that possibility.

Discussion ensued.

9.3 Issues delayed until Friday

None.

10. Plans for the future

10.1 Next meeting

The next meeting is in Kona: September 30 - October 6, 2007. This meeting will include an all-day session on Saturday.

10.2 Mailings

Nelson reported the following mailing deadlines:

post-meeting mailing	August 3, 2007
pre-Kona mailing	September 7, 2007

10.3 Following meetings

The next three meetings are as follows:

1. February 2008 in Bellvue WA
2. June 8-13, 2008 in Sophia Antipolis, France
3. November 2008 in Mountain View CA -- this meeting will be co-located with WG14

Spicer asked why the summer 2008 meeting is in June, rather than the more customary July. Dos Reis explained that scheduling in July is very difficult because of the Cannes Film Festival and the Monaco Grand Prix.

Plauger moved to thank the host. Applause.

Sutter thanked the committee for working so hard. Applause.

Motion to adjourn

Unanimous consent.

Attendance