Doc No:   SC22/WG21/N2848
                                                  PL22.16/09-0038
                                        Date:     2009-03-22
                                        Project:  JTC1.22.32
                                        Reply to: Robert Klarer
                                                  IBM Canada, Ltd.
                                                  klarer@ca.ibm.com

Minutes of WG21 Meeting, March 2, 2009

1. Opening activities

Clamage called the meeting to order at 09:00 (UTC-5) on Monday, March 2, 2009

1.1 Opening comments

Adamczyk described the arrangements and facilities for the meeting on behalf of Edison Design Group, Plum Hall, Dinkumware, and Sun Microsystems.

1.2 Introductions

Clamage had the attendees introduce themselves.

1.3 Meeting guidelines (Anti-Trust)

Clamage reviewed the patent disclosure rules.

The following materials were displayed without any further interpretation or discussion:

• http://www.incits.org/inatrust.htm
• http://www.incits.org/call.htm
• http://www.incits.org/pat_slides.pdf

1.4 Membership, voting rights, and procedures for the meeting

1.5 Agenda review and approval

Clamage presented the agenda (document PL22.16/08-0307 = WG21/N2797).

Plauger proposed the following amendment to the agenda:

Add agenda item 7.1.1: Special Math IS and Decimal TR so that these items will be discussed during the Thursday general session.

Motion to approve the agenda as amended:

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 7 papers in recent mailings that require discussion by among the CWG because they "may have some effect on us." Adamczyk also reported that the CWG has a large number of issues to process.

Library Working Group (LWG)

Hinnant reported that LWG has 13 papers and "several hundred" NB comments to process, in addition to the usual backlog.

Concurrency Working Group

Boehm indicated that the concurrency group may want to meet separately, but that their intention was to meet as part of library first.

1.7 Approval of the minutes of the previous meeting

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

Approved by unanimous consent.

1.8 Report on the WG21 Monday meeting

1.9 Liaison reports

SC22 Chair

Jaeschke reported that teleconferences have been sanctioned by JTC1. Teleconferences require two weeks' notice, but the first one requires four months' notice. It's recommended that calls be limited to two hours in duration. Jaeschke suggested that WG21 schedule a short telecon just to satsify the four month requirement.

Plum observed that if we announce today that we're going to schedule a teleconference on July 7, that would be 4 months from now. We could discuss the outcome of the telecon at the Frankfurt meeting.

Jaeschke also reported that the WG on vulnerabilities will next meet in San Diego. Their ocument is out for PDTR ballot.

Stroustrup: "I thought that this WG was originally meant to be temporary."

Stoughton explained that, when it was first proposed, SC22 suggested that the work on vulnerabilities be done within a rapporteur group, as it affects various other WGs. Instead, an the mechanism that was selected for this work was the OWG. The nature of an OWG is that they must be renewed each year. There was no intention that it would go away after a year.

Plauger expressed the belief that C and C++ have gotten "pretty good treatment from this group because of the involvement of people like Plum, Stoughton, and Jaeschke."

WG14 Liaison

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

• static_assert
• Raw strings
• UTF strings

Plum explained that there is a particular interest in keeping the lexical aspects of the two languages the same.

Nelson reported that "we have documents specifying memory model and Thread Local Storage that are ready for adoption by the C committee at the next meeting."

POSIX Liaison

Stoughton reported that the POSIX C++ working group binding meeting is this coming Saturday in New York City. The POSIX standard is now an IS. The document is already published by Open Group and IEEE. The PDF should be the same between Open Group, IEEE, and ISO.

1.10 Editor's report and WP approval

1.10.1 Draft WP report and approval

Document PL22.16/08-0310 = WG21/N2800

Approved by unanimous consent.

1.11 New business requiring actions by the committee

Plauger urged members to invite their employers to sponsor, in whole or in part, a meeting. Finding financial sposorship is a particular challenge in light of the economy.

Meredith reported that BSI does not think it's reasonable to have a fully conceptualized library for October, and is willing to accept a schedule delay in order to have a fully conceptualized library. BSI is also willing to accept an unconceptualized library, but is concerned about a partially constrained library.

2. Organize subgroups, establish working procedures.

Meredith reported that BSI thinks there should be an Evolution Working Group (EWG) meeting this week.

Plauger explained that public comments should first be addressed by LWG or CWG, but if it is necessary to reconstitute EWG or Concurrency to deal with an issue, then we would do so.

Stroustrup and Meredith agreed.

Brown noted that some NB comments affect both LWG and CWG and may require policy decisions; how to deal with these?

Plauger indicated that he would leave it to Adamczyk and Hinnant to decide how these comments would be handled.

Stroustrup suggested that these issues can be delegated to EWG.

Plauger summarized: anything that crosses boundaries belongs to EWG.

Plauger explained that the UK public comments may eventually differ in format from what we have today. We will have to work this week with what we have now, but the formal response document may need to be later revised to match the eventual format of the UK NB table.

Hedquist noted that responses should go in the last column of the table.

Plum asked about the Finnish Ballot comment.

Plauger explained that an attachment that explained a question on the Finnish Ballot was inexplicably stripped. We now have that attachment.

We have two subgroups: Core and Library. Evolution and Concurrency will be reconstitued as necessary.

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

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.

Core Working Group

We spent most of our time classifying national body comments and new core issues. For several dozen national body comments, we rejected the comment (as incorrect or unneeded, or as an extension that we don't choose to pursue at this time), or resolved it as quasi-editorial, or agreed immediately on the appropriate resolution and assigned a drafter to come up with the needed wording. For the rest, we will be creating core issues and discussing them further.

Several national body comments ask for features to be deprecated. As of now, we're inclined to recommend deprecation (not removal!) of trigraphs and the register keyword. We don't have an opinion yet on deprecating exception specifications and export.

Unified Function Syntax: We're working on improving the proposal. There will be no up-or-down vote in the CWG; we'll produce a good proposal and bring it to the full committee for a vote. Right now, it seems likely we will outlaw declaring-then-defining named lambdas, and possibly overloading of named lambdas. Also, we're trying to reduce parsing lookahead (and visual ambiguity): one small example is that "[]" would always introduce a function, not a lambda (where "lambda" implies "has non-empty capture list").

Motion 1: The usual motion about issues in Ready status in the latest Core Issues list, N2816. Issue numbers are 499, 542, 556, 564, 569, 571, 576, 588, 598, 628, 641, 645, 650, 652, 658, 665, 668.

Motion 2: N2841 "Consolidated Quasi-Editorial Changes ...". A number of very small issues from national body comments that we're prepared to handle immediately as quasi-editorial.

Motion 3: N2844 "Fixing a Safety Problem with Rvalue References: Proposed Wording (Revision 1)". Rvalue references can no longer bind to lvalues, thus eliminating a problem where "move" versions of functions sometimes don't interact properly in overload sets. The library part of this paper has been approved by LWG.

Motion 4: N2845 "Remove std::reference_closure". Remove the requirement that certain kinds of lambdas have reference_closure as a base class. The concern about efficiency has been adequately addressed.

Axioms: We'd like a straw poll on keeping or removing axioms from the language.

Responding to the desire to deprecate register Plum noted that, in C, register can be used to ensure that the address of an object has not been taken. That is particularly important in a multithread environment.

Adamczyk agreed, but noted that this is not C, and that register does not have that meaning in C++.

Wong expressed opposition to the deprecation of trigraphs, explaining that we're certain that trigraphs are being used. He doesn't consider digraphs to be a replacement.

Hinnant expressed concern that the interface of the forward function would be changed by Motion 3, above.

Stroustrup reviewed some of the recent discussion regarding axioms, noting that the following notation for equivalence in axioms has been suggested by UK and France:

e1 <=> e2

The <=> operator cannot be looked up, and it is not overloaded.

Stroustrup explained that axioms cannot be verified. Their primary purpose is to proved a clear and plain notation for stating the assumptions that are being made. It is a documentation feature. There is a tradition in programming languages for to provide a notation for semantic properties that can be used by external tools; this is something that is often requested by C++ users. The primary intention is not that this will be used with standard library types

Abrahams asked whether can you get undefined behavior if the program contradicts an axiom.

Stroustrup replied that you can create a system of axioms that is inconsistent, but only a theorem prover will be able to detect the inconsistency.

Abrahams: "If you write an axiom that is not satisfied by a type that models the corresponding concept, is that formally undefined behavior?"

Stroustrup: "I would think that is a bug."

Abraham asked whether a compiler is permitted to perform an optimization based on axioms.

Boehm answered that the canonical example is associativity for floating point. If we don't define exactly what's meant in this case, then I suspect that we are doing harm by adding axioms to the language at this time.

Maurer explained that, in his reading of 14.9.1.4/4, optimizers are granted the freedom to make algebraic transformations based on equivalence axioms and conditional equivalences.

Vandevoorde, responding to Maurer, suggested that it can be hard to determine whether a program has defined behavior or not, unless the programmer knows whether the optimization will be made.

Maurer expressed the opinion that we do not have adequate implementation experience to know that axioms are as useful as we hope, and that we may be crowding a syntax space that we might better use later. There may be some other formalism, such as tables that is better for expressing semantics than axioms.

Nelson stated that the effect of any expression can be the effect of any expression that can be deduced to be equivalent to the original expression by successive application of any number of axioms. So if any transformation has undefined behavior, then the original has undefined behavior.

Stroustrup explained that he doesn't think that compiler optimization is the main use of axioms.

Witt observed that we already have comments to describe the semantics of types. Further, he opinined that we are potentially opening this vast space of undefined behavior, and that is a potential political problem.

Boehm noted that, once you introduce an axiom that says "a - a = 0" you get potentially weird behavior, such as the substitution of "a - a" for zero if you've got "a" in a register somewhere.

Abrahams noted there are other places to put formal syntaxes, such as comments, that are intended for the use of tools, rather than the compiler.

Stroustrup explained that a code transformation tool that reads C++ and produces C++ can use axioms, and it need not be part of the compiler. These transformations tend to be too specialized to be supported by compilers, but they are valuable in very specific computational domains.

Meredith suggested that axioms seem as fundamental to concepts as requirements. They are a natural part of the process of designing a type.

Discussion ensued.

Plum asked whether axioms are syntax-checked comments, or can the compiler operate upon them?

Spicer explained that the compiler can use axioms to effect code transformations, but is not required to do so.

Nelson observed that it appears that a high-quality implementation should not use axioms to make code transformations.

Stroustrup explained that axioms allow researchers to do work on code transformations without first writing a C++ compiler. The compiler can do transformations, but is not obliged to; the compiler writer is obliged to avoid dangerous transformations.

Talbot asked "what compels me to write an axiom if I don't have an external tool? And how do I validate the correctness of the axioms that I have written, if the compiler doesn't check them?"

Boehm expressed concern that axioms will be interpreted differently by different tools.

Abrahams agreed, noting that a programmer who can't be confident about which axioms might be applied, and can't test her axioms, will logically have doubts about what my code does.

Stroustrup further explained that he wants to write a tool, and he wants C++ compilers to pass the information expressed by axioms to that tool. He want a standard notation for this information.

Maurer suggested that this would be a good topic for a Technical Report.

There was no concensus for the removal of axioms.

Library Working Group

Hinnant reviewed the LWG formal motions (see below).

7.1.1: Special Math IS and Decimal TR

A small subgroup met to discuss these two documents Wednesday, and all agree that they are ready for voting on Friday.

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

Core Working Group

See 10.1, below.

Library Working Group

See 10.1, below.

8. WG sessions continue

9. WG sessions continue

10. Review of the meeting

10.1 Formal motions, including DRs to be resolved.

Core Working Group

Motion 1
Move we apply the resolutions of all issues marked "ready" from N2816 to the C++0X Working Paper, i.e. issues numbered 499, 542, 556, 564, 569, 571, 576, 588, 598, 628, 641, 645, 650, 652, 658, 665, 668.

Approved by unanimous consent.

Motion 2
Move we apply N2841 "Consolidated Quasi-Editorial Changes for National Body Comments Concerning the Core Language" to the C++0X Working Paper.

Approved by unanimous consent.

Motion 3
Move we apply N2844 "Fixing a Safety Problem with Rvalue References: Proposed Wording (Revision 1)" to the C++0X Working Paper.

Hinnant read the following statement:

The function std::forward is a foundation cornerstone upon which much code will be built. We must get it right. It has had a stable interface for nearly 5 years. N2844 changes that interface in ways that I believe to be detrimental. I do not believe this change has received sufficient analysis by this committee. Even one of the authors of N2844 (maybe both) appears to be desiring an interface other than what is specified in N2844 (termed "P3" in LWG discussions).

If we apply N2844, we will put forward into a subtly broken state, not unlike auto_ptr or vector<bool>. Things will generally work until you explore the corner cases.

I recommend that we apply N2844 except for the section [forward]. This will put forward into a very broken state that must be fixed, instead of putting it into a subtly broken state that we may or may not fix. Doing so will avoid giving the priviledged state of "status quo" to an interface that I believe to be subtly incorrect, and is a departure from N2800 (CD1) and the past 5 years. This would be an act similar to the action we took with the time facilities when we voted them out, temporarily putting the WD into an inconsistent state.

A vote of yes for the entirity of N2844 will place a subtle bug into the WD. I urge us to instead place a very loud and noisy bug into the WD so that we *must* fix it. I'm asking that Motion 3 be modified to exclude the section applying changes to [forward]. This would turn my no vote into a yes vote.

Motion to amend as described in the statement above.

Abrahams disagreed with the severity of the concern raised by Hinnant.

Motion carries.

Voting on amended amended motion:

Move we apply N2844 "Fixing a Safety Problem with Rvalue References: Proposed Wording (Revision 1)", except for the section "20.2.2 forward/move helpers [forward]" to the C++0X Working Paper.

Approved by unanimous consent.

Motion 4
Move we apply N2830 "Problems with reference_closure" to the C++0X Working Paper.

Approved by unanimous consent.

Library Working Group

Motion 1
Move we apply the resolutions to the following issues from N2821 to the C++0X Working Paper:
752, 753, 758, 821, 866, 894

Approved by unanimous consent.

Motion 2
Move we apply Alternative 2 from N2802 "A plea to reconsider detach-on-destruction for thread objects" to the C++0x working paper.

Approved by unanimous consent.

Motion 3
Move we submit ISO/IEC TR 24733: C++ decimal floating point arithmetic extensions for DTR ballot as proposed in N2849 which contains two corrections.

Klarer reported that some technical glitches in the paper were discovered over the past two days, and that he'd like to withdraw the motion to address these.

Motion withdrawn.

Motion 4
Move we apply N2840 "Defects and Proposed Resolutions for Allocator Concepts (Rev 2)" to the C++0X working paper.

Approved by unanimous consent.

Motion 5
Move we apply N2836 "Wording Tweaks for Concept-enabled Random Number Generation in C++0X" to the C++0X working paper.

Approved by unanimous consent.

Motion 6
Move to apply the following editorial changes throughout Clause 5 [macro] of CD 29124 and to advance the resulting document for FDIS balloting:

1. Change the name of macro __CPP_MATH_SPEC_FUNCS to __STDCPP_MATH_SPEC_FUNCS__, and change its value from 200809L to 200903L.
2. Change the name of macro __CPP_WANT_MATH_SPEC_FUNCS to __STDCPP_WANT_MATH_SPEC_FUNCS__.

Approved by unanimous consent.

10.2 Future meetings:

See 11.1, below.

10.3 Issues delayed until Friday

None.

11. Plans for the future

FermiLab will be hosting an unofficial issue processing workshop May 18-20 2009. The host is Walter Brown. He needs to know of an member's intention to be there at least two weeks in advance of the meeting.

11.1 Next meeting

The next meeting will take place July 13 to 18 in Frankfurt, Germany. The meeting details are documented in PL22.16/08-0221=WG21/N2711 .

11.2 Mailings

Nelson reported the following mailing deadlines:

post-meeting mailing	March 20, 2009
mid-term mailing	May 1, 2009
pre-Frankfurt mailing	June 19, 2009

11.3 Following meetings

The following meetings are as follows:

1. October 19-24 2009, Santa Cruz CA

Nelson moved to thank the host. Applause.

Motion to adjourn

Unanimous consent.

Attendance