Doc No: SC22/WG21/N1629 J16/04-0069 Date: April 8, 2004 Project: JTC1.22.32 Reply to: Robert Klarer IBM Canada, Ltd. firstname.lastname@example.org
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:
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.
Motion to approve the minutes (document 03-0136/N1553):
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.
Plauger indicated that WG14 intends to begin work to produce three new Technical Reports -- one on each of the following topics:
Cooperation between WG14 and WG21 on the first two of these three items will be acheived through the mechanism of a Rapporteur Group.
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++.
Motion to accept the working paper (document 04-0017/N1577):
Motion to accept TR working draft (document 04-0036/N1596) as the working paper for TR work:
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
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
We have three subgroups: Core, Library, and Evolution.
The committee broke into subgroups at 12:00 (GMT+10:00).
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.
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.
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.
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.
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: Plauger |
|Seconder: Nelson |
Motion to adjourn
Meeting adjourned at 09:24(GMT-10:00)
|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|
|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|
|Indiana University||Jeremy Siek||V||V||V||V||V|
|Indiana University||Jaako Järvi||A||A||A||A||A|
|Mentor Graphics||Antonio Bigazzi||V||V||V||V||V|
|Metrowerks||Howard E. Hinnant||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|