JTC1/SC22/WG21 N1774

Document Number: JTC1/SC22/WG21 N1774=05-0034
Date: 2005-03-04
By: Lois Goldthwaite on behalf of the UK C++ Panel
(LoisATLoisGoldthwaite.com)



                     On the Future Evolution of C++

At the Redmond meeting it was decided to split the Evolution Working Group
into four tracks or subgroups, organised generally according to the perceived
motivation underlying each proposal:

- support for library building and generic programming

- modularity and libraries, including dynamic libraries

- safety, regularity, and performance (including security, threading,
and garbage collection)

- support for novices and incidental programmers


It is the position of the UK C++ Panel that organising the work, and
categorising proposals, along these lines is not sufficient.

We agree that breaking into smaller teams will allow participants to give
each proposal in their subset closer scrutiny, and thus achieve better-quality
reviews and subsequent translation into standardese. We hope that each
subgroup will attract participants with a range of perspectives and
interests, and not just a coterie of specialists in a certain area.

However, there is a danger that proposals put forward with different
motivations, and therefore being considered in parallel by different groups,
may relate to the same section of the C++ Standard and lead to infelicitous
interactions. Someone must ensure that the teams are not
working on overlapping issues -- race conditions are universally
acknowledged as a bad thing, in standards development as in software.

At a minimum, proposals should be categorised according to a set of
technical considerations (orthogonal to motivation) to insure that they
are scrutinised from a range of perspectives and so that unintended and
unfortunate interactions are prevented if at all possible.

As an example of two proposals which in our opinion should have been
considered simultaneously, see N1719, "Strongly Typed Enums (revision 1),"
and N1706, "Toward Opaque typedefs in C++0X" (in our opinion, the latter
proposal offers all the benefits of the former and more).

All proposals should be evaluated in relation to the strategic aims of
21st-century C++. Here we put forth some strawman text suggesting what
we see as the factors of most strategic significance in this effort
(the alliteration is accidental, honest):

- Memory Model: a rigorously-specified virtual machine whose semantics
can serve as a reliable foundation for systems programming, particularly
programs intended to run in multithreaded and multiprocessor environments.
Once the virtual machine has been specified, proposals for threading
libraries and concurrent execution can be built on top of it. Most if not
all current multithreading libraries are based on the concept of a single
process swapping between different threads of execution. Now that multi-core
and multi-processor machines are appearing on the desktop, true concurrency
is becoming an issue for even entry-level systems.

- Modularity: a system for partitioning applications in such a way that
only intended interactions are possible. A portable mechanism is needed
to prevent unintended interactions, such as accidental name conflicts.
These are problems that programmers face every day in real life, and
will face more often as applications become increasingly complex, often
assembled from components acquired from different sources.

- Metaprogramming and generic programming: this addresses ways for
programmers to express even more powerful abstractions in C++ (albeit with
some risk of brain damage from angle-bracket-overload). But we hope that some
attention can also be paid to increased expressiveness on behalf of people
with more modest aspirations, such as the incidental programmers who write
programs only to support their other work, such as scientific research. These
people are woefully under-represented in WG21, and can too easily be forgotten.
Strengthening the type system, smoothing syntactical irregularities, and
providing libraries of useful (and readily-used) components would help
address their needs. It is important to keep in mind how these people
can benefit from the powerful artifacts produced by generic programmers
when evaluating leading-edge proposals for inclusion in C++0x. Template
typedefs could be useful to everyone. If there are two subgroups considering
proposals aimed at high-end and low-end programmers (I regret the pejorative
phrasing but a deadline is looming), then each should make special efforts
to keep the aims of the other group in mind.

- Migration: As a priority, C++ needs to develop a strategic vision for
the next version of the standard library. Will it duplicate all the best
bits of the current std::, while dropping bits now thought to be
ill-conceived? Or will std2:: provide only new capabilities, with the
current std:: continuing to exist alongside it? Will it be possible to
use both std:: and std2:: functionality within the same program? (If not,
then the concept of namespaces is a failure.) If the decision is to keep
the existing standard library and add lots more stuff to std::, then we
will reveal an appalling lack of strategic vision and miss an important
opportunity. Library versioning is another real-world problem that people
face every day; WG21 can show leadership in how to deal with it cleanly.


The above is not to argue that subgroups should necessarily be structured
on these divisions (or on any basis other than a proportional allocation
of the evolution group work). We do suggest that all submitted proposals
should be weighed to see how they contribute to the strategic needs of C++.
Some which could provide value but do not fit the strategic aims might be
better handled in TRs or postponed. Indeed, we can see some good arguments
for setting up a subgroup of WG21 to concentrate on proposed Technical
Reports, freeing the other groups to concentrate on proposals aimed at
inclusion in the standard.

Because progress in WG21 is driven by papers submitted by individuals
who are willing to take the lead in advancing them, there is a danger
that the overall strategic aims may be lost, simply through lack of a
champion. Herb Sutter has previously raised the migration issue above
for discussion, but because no one put forward an easy solution to the
problems, the discussion foundered. Nevertheless, this is a very important
issue and must not be neglected.


We anticipate that relevant technical categories will be deduced from
clusters of papers and may change over time, but here are some axes
we have identified which provide different perspectives for viewing
proposals. They are orthogonal [or at some other acute or oblique
angle in relation] to the categories discussed above and also to the
principles adopted to guide development of C++0x.

- Anything that relates to systems programming

- Static checking vs runtime checking

- Strengthening the type system

- Removing warts, asymmetries, inconsistencies, and other carbuncles from
language and library

- Trust the programmer vs protect the programmer from any possible error

- Abstraction mechanisms (and not just at the bleeding edge), expressiveness
and general code simplification

- More library components in useful domains (so every programmer need not be
an expert in all domains -- for example, many people need to do mathematics-
based programming without wanting to become leading experts in programming
mathematics routines).



We hope this paper can provide some input to further discussions on the

division of work in the Evolution Group.