Doc No: SC22/WG21/N1629 J16/04-0069 Date: April 8, 2004 Project: JTC1.22.32 Reply to: Robert Klarer IBM Canada, Ltd.

Minutes of J16 Meeting No. 38/WG21 Meeting No. 33, March 22-26, 2004

1. Opening activities

Clamage called the meeting to order at 09:03(GMT+10:00) on Monday, March 22, 2004

1.1 Opening comments

John O'Brien welcomed everyone to Sydney and described facilities for the meeting.

1.2 Introductions

Clamage had the attendees introduce themselves.

1.3 Membership, voting rights, and procedures for the meeting

Clamage reviewed membership and voting rules. Nelson circulated the attendance list and membership list.

1.4 Agenda review and approval

Clamage presented the agenda (document 04-0020/N1580).

Miller pointed out that we need to formally accept the working paper in the pre-meeting mailing. Clamage agreed to add this item under 1.9.

Austern suggested that the library TR draft should also be added under 1.9.

Nelson noted that there will be a US TAG meeting added to the agenda for Friday after closing of the WG21 meeting to vote on the Performance TR ballot.

Thorsten Ottosen introduced two new papers: one on imaginary types, and another on design-by-contract.

Stroustrup introduced a paper on #scope via e-mail.

Motion to approve the agenda as amended:

Mover: Miller
Seconder: Brown
WG favor oppose abstain
J16 lots 0 0

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

Adamczyk indicated that the Core Working Group (CWG) would not be bringing any proposals for extensions to the committee for formal votes. Most of the CWG's time would be spent meeting in common with the Evolution Group.

Abrahams noted that the topic of conditionally-supported behavior was of interest to members of the Library Working Group, as well as the CWG and the EWG.

Adamczyk offered to alert individuals in LWG who had an interest in this topic before it was discussed so that they could participate.

Sutter noted that there are 7 papers with proposed wording and 12 more papers that merit discussion. Sutter noted that late papers and papers whose authors were not present at this meeting would be given low priority.

Brown requested that the various working group chairs or their delegates use the Wiki to indicate when each topic was scheduled to be discussed.

Austern reported that much of the time of the LWG will be devoted to issue processing, both in the Working Paper and in the Library TR. Important issues to decide that are not in the Issues Lists: there has been a proposal to remove iterator adaptor and facade from the TR and to move it to the WP as well. There has been a proposal to add C99 library facilities to the TR.

Sutter remembered that the EWG intended to discuss possible policies on C compatibility.

Austern asked whether the LWG would have to participate in that discussion to reason intelligently on the proposal to add C99 library facilities to the TR.

Plauger suggested that a full session should be conducted to discuss policy on C99 compatibility.

Sutter agreed to conduct this discussion in committee of the whole.

Goldthwaite reported that the Performance TR is at draft ballot. The Performance working group will not convene at this meeting.

1.6 Approval of the minutes of the previous meeting

Motion to approve the minutes (document 03-0136/N1553):

Mover: Miller
Seconder: Brown

WG favor oppose abstain
J16 lots 0 0
total votes: 16

1.7 Report on the WG21 Sunday meeting

Sutter reported that 5 countries were officially represented at this meeting, and that the drafting committee for this meeting was composed of Adamczyk, Clamage, Sutter, and Vollman.

Action item from previous meeting: we needed an up-to-date working draft, and the previous Project Editor, Andrew Koenig would not be able to reliably attend meetings. P J Plauger and Pete Becker prepared a WP for this meeting. Becker has been named as the new Project Editor.

It was decided on Sunday night that the membership list and TG5 liaison reports will not be public documents, but all other committee documents will be available to the public, including Working Drafts.

The issue of whether non-members will, in the future, be permitted access to the reflector was discussed on Sunday night, and it was resolved that Sutter will decide whether non-members will be permitted access to the reflectors, and he wil be inclined to refuse to grant new access to non-members.

1.8 Liaison reports

WG14 Liaison

WG14 is publishing two TRs

Plauger indicated that WG14 intends to begin work to produce three new Technical Reports -- one on each of the following topics:

  1. decimal arithmetic -- WG14 very much wants to coordinate this work with WG21 to avoid gratuitous incompatibilities between the two languages.
  2. special mathematical functions -- WG14 wants to adopt the work done in this domain by WG21, again to avoid gratuitous incompatibilities.
  3. security in the C library

Cooperation between WG14 and WG21 on the first two of these three items will be acheived through the mechanism of a Rapporteur Group.

TG5 Liaison

Plum reported that, at the TG5 meeting in Kona, the group decided to try to avoid standardize things that were of interest to WG21 without first trying to coordinate with WG21. Some of those items are proposed in the form of papers in the WG21 pre-Sydney mailing. These items are nullptr, constructor forwarding, properties, strongly-typed enums, and for_each.

Sutter added that there are things that are discussed in TG5 for which there are no corresponding WG21 papers, including "sealed," "overload," and garbage collection.

Austern asked whether TG5 is working on extensions that WG21 has already explicitly rejected. Bray responded that 'finally' is an example of this.

Plum suggested that the greatest danger is that CLI will have similar notation to C++, but with different meaning, or different notation than C++ for features that are otherwise common with C++.

1.9 New business requiring actions by the committee

Motion to accept the working paper (document 04-0017/N1577):

Mover: Plauger
Seconder: Glassborow

WG favor oppose abstain
J16 lots 0 0
WG21 5 0 0

Motion to accept TR working draft (document 04-0036/N1596) as the working paper for TR work:

Mover: Austern
Seconder: Plauger

WG favor oppose abstain
J16 lots 0 0
WG21 5 0 0

Committee of the Whole discussion on C compatibility

Sutter reported that, at the last meeting, the C and C++ committees both showed a strong interest in working together to avoid gratituitous differences between the two languages. C and C++ have contributed to each other since the 80's. Sutter suggested that C99 (not the TRs) be integrated into C++ by default as long as there were no considerable barriers to implementation, particularly where C99 features do not have broad implications to the whole of the language.

Plauger indicated that there is a way to blend the C99 and C++ libraries "without much grief." Plauger noted that the C99 library cannot be directly bolted onto the C++ library: C99 complex numbers, for example cannot be reconciled with C++ complex numbers.

Austern asked about the C99 <fenv.h> header. How does this affect C++?

Plauger replied that this header can be implemented without the use of C99 language features that are not already available in C++. The committee should add as much of the C99 library to C++ as possible, but this should be accomplished without using C99 language features that are not common to C++.

Adamczyk noted that some C99 language features can be added directly to the C++ core language, like restrict, but that there are things that should not be done in the language because they are better done in the library, such as complex.

Austern asked about compatibility of features that exist in both languages, but in different forms. Specific examples include bool and inline.

Glassborow suggested that a document that would lend advice to programmers on porting between C and C++ would be helpful; probably more so than a list of incompatibilities.

Plauger proposed a different formulation of Sutter's proposed policy statement: we should consider doing things as they have been done in C99, but we should do things in the library when it makes most sense to do so, even if C99 did these things in the core language.

Hinnant wanted to agree with Plauger, but suggested that we must consider performance when deciding whether to do something in library or core language.

Brown expressed a desire for a specific procedure for the two committees to work together and to review the work of each other.

Sutter observed that such a procedure has been established for work on the decimal TR and the special math functions.

Glassborow observed that anything that is in a standard library should be capable of implementation through compiler magic. Templates inhibit that somewhat.

Austern identified two goals for the integration of C99 features into C++

Sutter indicated that he had thought of a different pair of goals:

Plum recommended to people that want to influence liaison between the two committees that they join both committees. Plum spoke against language convergence, recognizing that C and C++ target different application domains. C, in particular, is commonly used in embedded programming.

Spicer commented that "...the convergence issue, in my opinion, has been dealt with."

Crowl observed that divergence in the content of the header files causes problems in C++. Unix systems must have conforming C headers.

Austern stated that we should put high priority on making the C++ headers more like the C headers. We should get in touch with the standards agencies (such as POSIX) that govern the contents of the system header files to ensure that these headers are written, as much as possible, in the common subset of the two languages.

Spicer recommended that the committee consider adding to C++ those C99 features that can be added in such a way that compatibility with C++ 2003 can be maintained, but we should not, for example, change inline for consistency with C99.

Brown asked what criteria will be used to make decisions about the adoption of individual C99 language features.

Nelson responded that, as always, individual members will vote according to their own criteria.

Sutter suggested the following policy on C99 compatibility: by default, we will consider for adoption C99 features unless there is a difficulty, for example, in integration with C++ features. Adoption will be done in such a way as to achieve, as much as possible, source compatibility between the two languages.

Brown reported that he thinks that a default disposition toward adoption is dangerous

Siek observed that Sutter's statement did not reflect a preference for library solutions over language solutions.

Miller: "...and the header thing."

Witt asked whether C is going to make efforts to ensure that future language extensions can be implemented in C++ as libraries. Plauger indicated the he will try to guide the C committee in that direction.

Plauger recommended a straw poll on the committee's desire to undertake a program of work to review the whole of C99 standard to establish the cost of adopting C99 features.

straw poll results
in favor lots
opposed none

Austern suggested that we should ask for volunteers to do this work.

Meredith asked what the product of this program of work will be. Plauger replied that there are two possible products: a document that is essentially a rationale, or a tutorial such as Glassborow suggested

Nelson suggested that another such product might be an expanded Appendix C

2. Organize subgroups, establish working procedures.

We have three subgroups: Core, Library, and Evolution.

The committee broke into subgroups at 12:00 (GMT+10:00).

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

4. WG sessions continue.

5. WG sessions continue.

6. General session.

6.1 WG status and progress reports.

Core Working Group

Adamczyk presented Core Working Group (CWG) status and formal motions to be made Friday (see 8.1, below).

Library Working Group

Austern presented Library Working Group status and reviewed formal motions to be made Friday (see 8.1, below).

In response to the formal motion to propose a New Work Item to produce a second TR on C++ library extensions, Vandevoorde observed that time will have to be devoted to the integration of TR libraries into the C++0x working paper, and inquired as to how this will affect LWG's work. Austern responded that the LWG could manage this addition to its workload.

Maurer asked what would happen if C++0x were to be published soon after TR2. Specifically, he asked whether TR2 might conflict with C++0x, and whether users might be confused. Austern replied that TR2 can make reference to specific language extensions. Also, if there is danger that this will happen, we can simply discontinue work on TR2.

Plauger explained that TR2 will be valuable as a safety-valve. It allows the pipeline for considering new libraries to stay open.

Ottosen asked whether language changes be considered for TR2? Austern answered that this is a possibility.

Vandevoorde asked whether this new document could be considered to be a language-wide TR, rather than simply a library TR.

Abrahams noted that, in some sense, core extensions are riskier and have greater weight than library extensions, so using a TR to proof language changes is potentially dangerous.

Austern commented that another idea is to have two TRs: one for library, one for core.

Spicer suggested that certain core features could benefit from being specified first in a TR.

Sutter expressed concern that a core TR would necessitate two Working Papers. Spicer observed there is a precedent in C for this practice

Miller asked how a core TR will differ from a publicly available WP. What are the criteria for deciding what goes into the TR and what goes into the WP?

Crowl suggested that the TR should not break existing code, and that limits the scope and usefulness of a TR.

Plum requested an explanation for the desire for a second library TR.

Plauger explained that there was a sense among LWG that the library would begin work on TR2 provisionally. If the schedule for C++0x permitted, the LWG would later consider rolling the content of TR2 into the WP and cancelling publication of TR2. The TR process gives LWG a means to manage the growth of the library. Plauger suggested that a common core and library TR could be difficult to manage, organizationally.

Nelson commented that a second library TR could be useful if nothing that is specified in that TR is intended for publication in C++0x, and asked whether it is reasonable to expect that a TR is more likely to produce implementation and usage experience than a publicly available WP?

Austern stated that he believes that the answer to this question is "yes." The balloting process and the authority of a TR make implementation and subsequent usage more likely than is the case for a public WP.

Nelson noted that there is a conflict between the sense that a second TR will produce implementation experience and the principle that no proposals will be accepted into C++0x that have not been implemented.

Sutter observed that having a Work Item permits us to publish a second TR if required in the event of a delay of the publication of the revision of the standard.

Vandevoorde suggested that a TR will help to prioritize effort for implementers and the committee, particularly in deciding which features will be implemented first.

Evolution Working Group

Sutter presented Evolution Working Group (EWG) status and formal motions to be made Friday (see 8.1, below).

Sutter reported that the Evolution Working Group (EWG) met jointly with Core for most of the week. EWG was on track to cover all its papers, including late papers before Friday. EWG did not intend to bring forward any extension proposals to the full committee. Members interested in checking a particular proposal's status were instructed to see the meeting Wiki for a record of all straw polls, or to see the post-meeting mailing for an updated proposal list.

Sutter also reported that EWG has adopted procedures for its proposal processing, which are based on the CWG/LWG procedures for issue processing. Vandevoorde volunteered to be proposal list maintainer. EWG and CWG have adopted the requirement that a C++ extension proposal must meet the following three requirements before it may be moved to Ready status: a) it must be useful to users; b) it must be well specified; and c) it must be implementable, meaning that either an implementation exists or there is consensus among implementers that it is implementable.

Future meetings:

Sutter reviewed discussion of the possibility of convening three times each year, rather than just twice.

Benito expressed concern that the invitation for the April 2005 meeting was not yet sufficiently firm.

Glassborow recommended that the dates for meetings be fixed at least 18 months in advance.

Austern stated that he believed that we would make faster progress if LWG met three times per year. He also observed that it was likely that attendance would decrease if the committee met three times per year, and it's not clear where the trade-off lies.

Glassborow noted that it would be difficult to find enough hosts to be able to sustain a three meeting-per-year schedule.

Miller suggested instead the establishment of a regular, periodic web-conference.

Plauger suggested that, practically, we can't meet three times per year for many reasons, and agreed with Glassborow that it will be difficult to find hosts.

Bigazzi noted that, since some members will have difficulty attending three meetings a year, they will miss meetings and there will be a consequent loss of continuity between meetings.

Plum suggested that a Wiki is close to all that is needed in terms of sharing documents. Also, teleconferences work well; though you can't take formal votes at a teleconference, much productive work can be completed.

Abrahams mentioned that it is harder to search the reflector archives than it should be. Abrahams also indicated the need for a structure that allows the committee to get work done between meetings, and spoke in favor of the sort of on-line collaboration that occurs among Boost contributors.

Meredith spoke in favour of extra mailings.

Austern supported the suggestion of intermediate mailings. Austern also commented that we are missing a mechanism for coming to concensus and making decisions online. Trying to get more work done between meetings is important, but we don't know how to do that yet in this group.

Plauger stated his belief that is not possible to come to concensus online and that we shouldn't even try. Focus is important to make more efficient use of our time, and the subgroup chairs have been good at this. One way to use time more efficiently is to observe where time is wasted. A tool that will allow us to waste less time is to assemble a travelling LAN so that we don't spend productive time setting up connections each morning.

Abrahams opined that we can get close to concensus online and suggests that the Boost formal approval process could be applied to WG21 papers.

Austern suggested that model is applicable to extension proposals, but not to the bulk of the work in the CWG and the LWG, which is processing issues.

Benito observed that there is an Incits requirement that the minutes be distributed soon after the meeting.

Hinnant asked whether we could keep to a two mailing schedule but encourage paper authors to make papers available independently of mailings, ahead of time.

Nelson noted that people need deadlines, and suggested that we could say that there will be a mailing deadline and allow people to vote with their pens. If papers arrive, a mailing will be assembled.

There was unanimous consent in favor of an additional mailing.

Abrahams stressed the potential value of something like the Boost formal review process.

Plauger suggested that Abrahams select an issue or two and shepherd them through such a process.

Marcus and Siek voiced their approval of Abrahams' idea.

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

see 6.1

7. WG sessions continue

8. Review of the meeting

8.1 Formal motions, including DRs to be resolved.

Austern moved to thank the host. Applause.

Crowl moved to thank Maurer for maintaining the meeting LAN and Wiki. Applause.

Abrahams moved to thank the committee. Applause

Becker noted the contribution of EDG in editing the Working Paper

Becker also moved that WG21 thank Andrew Koenig for his extensive and distinguished service as our project editor over the past decade. His valuable work and tireless effort are widely recognized as an essential factor in the success of C++ standardization, and WG21 greatly appreciates his important contribution to the evolution of C++. Applause.

Core Working Group motions

Move to advance the following core working group issues to DR status, and apply them to the Working Paper:

11, 125, 328, 351, 352, 362, 379, 383, 387, 390, 392, 396, 398, 400, 403, 404, 406, 421, 424, 425, 428, 432, 433

(This is the list of issues in Ready status in J16/04-0011=WG21/N1571.)

Mover: Adamczyk
Seconder: Miller

WG favor oppose abstain
J16 16 0 0
WG21 5 0 0

Library Working Group motions

Evolution Working Group motion

Move that WG21 undertake to review the remaining differences between C++ and C99, with the goal of minimizing source-level incompatibilities, and update Annex C to summarize whatever differences C++ chooses to retain.

Mover: Plauger
Seconder: Nelson

WG favor oppose abstain
J16 15 0 1
WG21 5 0 0

8.2 Review of action items, decisions made, and documents approved by the committee

8.3 Issues delayed until Friday

9. Plans for the future

9.1 Next meeting

Plans for the meeting in Redmond were reviewed.

9.2 Mailings

Nelson reported that the deadline for the post-meeting mailing will be April 9, the deadline for the mid-year mailing will be July 16, and the deadline for the pre-Redmond meeting mailing will be September 10.

9.3 Following meetings

covered on Monday.

Motion to adjourn

Mover: Plauger
Seconder: Glassborow

WG favor oppose abstain
J16 16 0 0


Meeting adjourned at 09:24(GMT-10:00)


Company/Organization Representative Mon Tue Wed Thu Fri
Abrahams David Abrahams V V V V V
Adobe Systems Mat Marcus V V V V V
Apple Computer Matthew Austern V V V V V
Charney & Day Reg Charney N N N N N
Dinkumware P. J. Plauger V V V V V
Dinkumware Pete Becker A A A A A
Dinkumware Tana Plauger A A A A A
Edison Design Group J. Stephen Adamczyk V V V V V
Edison Design Group John H. Spicer A A A A A
Edison Design Group Daveed Vandevoorde A A A A A
Fermi Nat. Accelerator Lab Walter E. Brown V V V V V
Fermi Nat. Accelerator Lab Marc F. Paterno A A A A A
IBM Robert Klarer V V V V V
IBM Sandor Mathe A A A A A
Indiana University Jeremy Siek V V V V V
Indiana University Jaako Järvi A A A A A
Intel Clark Nelson V V V V V
Mentor Graphics Antonio Bigazzi V V V V V
Metrowerks Howard E. Hinnant V V V V V
Microsoft Jonathan Caves V V V V V
Microsoft Herb Sutter A A A A A
Microsoft Brandon Bray A A A A A
Perennial Barry Hedquist V V V V V
Plum Hall Thomas Plum V V V V V
Sun Microsystems Lawrence Crowl V V V V V
Sun Microsystems Stephen D. Clamage A A A A A
The Mathworks William M. Miller V V V V V
Zephyr Associates Thomas Witt A A A A A
ACCU Francis W. Glassborow N N N N N
DB Systems Jens Maurer N N N N N
LM Ericsson Finland Attila Feher N N N N N
Phaidros Software Dietmar Kühl N N N N N
Vollman Engineering Detlef Vollman N N N N N
Lois Goldthwaite N N N N N
Alisdair Meredith N N N N
Thorsten Ottosen N N N N N