Direction for ISO C++

gistfile1.txt

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0939r0.pdf

Directions for ISO C++
DWG
 P0939
r0
9 
unions, low
-level use of variants, and eliminate the visitor pattern (which is an expensive 
workaround that confuse
s   many).
•
Exception and error returns
: There are still people who argue against all use of exceptions and 
people 
who 
claim that
 exceptions should be used consistently instead of error codes. We’d like 
to see a clear articulation of where each alternative is ideal, but until we do that we should be 
careful about what error-
handling strategies we support.  The contracts proposal
 (
A Contract 
Design 
[GDR,2016]) 
should simplify this by taking care of many nasty cases
. 
•
Static reflection
: C++’s lack of run
-time reflection is an essential strength in some areas (such as 
small embedded systems), but lack of simple reflection in specific areas have let many to switch 
to alternative language
s. In particular, the lack of abi
lity to generate 
serializer/deserializer pairs 
and object layout maps ha
s been painful in many areas.
•
Modern networking
: We need the networking as specified in the networking TS (
[Wakely,2017]
) 
urgently needed (on the C++20 timescale), but beyond that we n
eed good simple support for 
interaction with modern browsers and networking (http, html5).
•
Modern hardware
: We need better support for modern hardware
, such as executors/execution 
context, affinity support in C++ leading to heterogeneous/distributed compu
ting support, 
SIMD
/task blocks, more concurrency data structures, improved atomics/memory model/lock
-
free data structures support. The challenge is to turn this (incomplete) laundry list into a 
coherent set of facilities and to introduce them in a manner t
hat leaves each new standard with 
a coherent subset of our ideal.
•
Simple graphics and interaction
:  Command
-line options and console I/O, while still useful in 
various contexts, haven’t been the primary way of interacting with software for decades.  
Althou
gh modern interactive
 applications deal with broadly varying devices, almost all are 
controlled using an
 “event
-driven” software model and most involve a graphical screen.  We 
think the C++ 
standard library needs a component providing (a) a graphical 
canvas with basic 
geometric
 drawing, text rendering, and bitmap output primitives, (b) a simple input API for that
graphical canvas abstract enough to deal with both “click” and “touch” events, and (c) a simple, 
highly
-abstract “menus and dialogs” system (
again, abstract enough to not force
 surfacing 
distinctions between devices as disparate as “phones” and “desktop computers”).
 Such a 
component will, of course, be “optional” to allow for platforms that don’t have
 the needed I/O 
facilities.  Practical uses 
of this component should be simple enough
 to be teachable to first
-year 
students.
 Improved Unicode support.
•
Anything from the Priorities for C++20 that didn’t make C++20
: see 
Priorities for C++20
. 
We feel that work on a database interface is badly needed, but since there seem to be no current work 
on that in the committee and no critical mass of expertise and interest, we can’t put it on our list
. 
5.
Priorities
 for C++20
We are very sympathetic 
to Ville Voutilainen’s
 proposal 
To boldly suggest an overall plan for C++20
[Voutilainen,2017
]  to restrict new features to a limited set of significant proposals. Our list differs in 
detail:
•
Concep
ts (a large part of the TS is already in the WP)
•
Modules (
offering proper modularity and dramatic compile
-time improvements
) 
Directions for ISO C++
DWG
 P0939
r0
10
•
Ranges (
incl., some of the infinite sequence extensions to the TS
) 
•
Networking
 (Extensions for Networking
[Wakely,2017])
•
Concepts in the standard library
Beyond that
, if time allow
s   while giving priority to the top issues for committee time
,  we recommend
: 
•
An 
(optional) Graphics API TS
 (see 
A Proposal to Add 2D Graphics Rendering and Display to C++
[McLaughin,2017]).
•
Simple 
Reflective Metaprogramming TS
 (relying 
on “ordinary C++” 
rather than
 template tricks).
•
Contracts
 as specified in [GDR,2016], [G
DR,
2017]
. 
•
Calendar functions and time zones (
Extending <chrono> to Calendars and Time Zones
; 
[Hi
nnant,20
17
]). 
•
Coroutines [Nishanov,2017]
.  
•
A high
-level (and simple
-to-use) API for common modern networking and browser use (HTML in 
particular and including Unicode support) TS
 (an example
 in current use:  WT
) 
Additions beyond that should be discourage
d as time sinks and distractions. Proposals for minor 
features should be given priority if and only if they support the priority items.
 The last point is only 
feasible if someone can point to an existing system th
at could be turned into a proposal.
A significant
 part of the C++ community is panicked by fears of massive growth of features and 
complexity
.  This leads to disuse of novel features. T
he complexity of C++ and the difficulty of learning it 
are major barrie
rs to increased use. No feature is cost free, there is always the implementation cost, the 
cost of producing teaching material, the time needed to learn, the opportunities for confusion
, and the 
inevitable distraction from overselling.
We chose to prioritize these particular proposals because they
•
relate 
directly 
to 
the 
long
-term
 and medium
-term aims
•
are advanced with impl
eme
ntations and have user experience
•
have people dedicated to their completion and improvement
When approaching these proposals try to ma
ke sure 
that a proposal
•
actually offer
s   the expected
 benefits
•
handle
s   the primary use cases simply and elegantly
•
isn’t delayed by a futile insisten
ce
 of theoretical perfection
•
isn’t complicated to please every possible expert need
Once we known the approximate final goal, we should
•
Use an incremental approach to design to benefit from actual experience
Our nightmares include a module system that doesn’t offer modularity (e.g., where the order of import 
is significant or the compile
-time cost of using
 modules approaches that of #includes) and a reflection 
system that is so integrated with general metaprogramming that nothing can be delivered until C++23 or 
later and significantly increase
s   compile
-times. Note that the cost of compilation is among the l
oudest 
reasonable complaints about C+
+ from its users.
Directions for ISO C++
DWG
 P0939
r0
11
6.
Process Issues
We are “a bunch of volunteers.”
•
Most are enthusiasts for some aspect of the language or other
. 
•
Few have a global view (geographically, C++ community, C++ usage, C++ Language and standard 
library).
•
Most
 have a strong interest in some subset of use, language, or
 library.
•
Most are deeply engaged with a specific form of C++ as part of their daily work.
•
Our levels and kinds of relevant 
computer
-science, design, and programming language
education vary dramatically
. 
•
Many are clever people attracted to clever solutions.
•
Some are devoted to ideas of perfection.
This implies that w
e can’t rely on a common vocabulary
,  a core set of shared values, a 
common set of 
basic ideals, or a common unde
rstanding of w
hat’s a problem. Consequently, we must
•
Spend more effort articulating rationales for proposals
. 
•
Spend more effort providing facilities for the “average programmer,” who is seriously 
underrepresented on the committee.
Please pay special attent
ion to that last point. We feel that C++’s utility and reputation suffer badly from 
the committee lacking attention to improvements for relative novices and developers with relatively 
mundane requirements. Remember:
•
Most C++ programmers are not like the me
mbers of the committee
We, as a committee, have no mechanism of reward (except accepting someone’s proposal) or 
punishment (except delaying or rejecting someone’s proposal). To get something accepted, we need 
consensus (defined as large majority, but not n
ecessarily unanimity).
 This has implications on what we 
can do and how we do it.
•
Nothing gets done unless someone cares enough to do it
•
A small vocal minority can stop any proposal at any stage of the process.
Currently, C++ is probably as popular as it has ever been and there are definitely more active members 
of the standards committees than ever before. One effect of this enthusiasm for C++ is to inundate us 
with a flood of proposals. The sheer volume of prop
osals leads to few
er proposals getting through the 
processes to get accepted. 
Some proposals become warped from the need to gain support in an 
environment where time to think and present ideas is limited. Many of these proposals come from 
people who are un
acquainted with standardization. We understand that some new members
 find it 
hard to accept that
•
Progress is less rapid than for
 their corporate and open source projects
. 
•
Concerns that are essential to them are not given priority by the committee.
•
Committe
e members don’t 
all 
understand or 
accept their experience and design principles
. 
•
Standardizing for decades differs dramatically 
from shipping the next release with the fewest 
number of bugs
. 
Directions for ISO C++
DWG
 P0939
r0
12
•
There are millions of programmers who use C++ in ways that differ 
from what they consider 
normal
 and reasonable.
•
“No bugs” does not imply that a proposal is good
. 
•
“There are bugs” does not imply that a proposal is bad (there is a saying among
 mathematicians 
that the way to recognize an important result is by the number 
of errors in its initial proof –
 it is 
relatively simple to provide a flawless proof for
 a trivial result
). 
•
“Good enough” isn’t always good enough because a second look at the problem might come up 
with a better, more general, or better integrated solution
. We have to consider the long term.
•
90% or more of the work of getting a proposal into the standard is ensuring that it fits smoothly 
with other facilities (language and standard library)
. 
•
Stability/compatibility is an essential feature.
And still some im
provements are urgent. However, in the context of the committee “urgent” still implies 
“years” of work/delay. Novices
 are not the only ones who are impatient, but 
we must try to channel our
energies into constructive activities. 
We encourage members (old a
nd new)
•
to get acquainted with C++’s history and design rules
•
to accept or contribute to 
our long-
term aims for C++
The aim of most members, new or “vintage” is to improve C++ by hav
ing their favorite proposal 
accepted. However, the sheer number of proposals (constantly on the order of a hundred) and the 
number of papers (running at more than one hundred for each meeting)
, not even every 
good
 proposal 
can be accepted. We encourage everyone to ask themselves
•
Is my proposal among the top
-20 in terms of long
-term benefit to the C++ community as a 
whole?
•
Is my proposal essential for some important application domain?
Push only very gently if the answer
s are
 “no
,”  “sort of,” 
or “I don’t kno
w” and redirect effort to 
proposals for which the answer is “Yes!”
 We encourage
 the WG chair
s to 
•
Focus on the major high
-level and intermediate
-level goals
•
Articulate 
the goals as they relate to their WG
•
Prioritize
 proposals based
 on those goals
•
Discourage
 proposals 
not in
 that scope
•
Discourage
 proposals 
from being re
-submitted
 with only minor changes after rejection
(especially if the revised proposal does not include new insights into the problem to be solved)
. 
We are a set of interrelated committees with
 about 130 members present at a meeting and more active 
via the Web. Thus some “design by committee”, or rather “design by committees
,” is unavoidable. We 
need to consciously and systematically try to minimize those effects by building a shared sense of 
di  rection.
•
We have no shared aims, no shared taste.
This is a major problem, possibly the most dangerous problem we face as a committee. For C++ to 
succeed, we must overcome that. For starters, we 
– as individuals, as SGs
, as WGs, and as the 
committee as a whole 
– must devote more time to develop and articulate common understanding.
Directions for ISO C++
DWG
 P0939
r0
13
•
The alternative is a dysfunctional committee producing 
an incoherent language.
We need to be more explicit about
•
What general problems we are trying to address
•
How a particular p
roposal serves those articulated aims  
If would also be a great improvement if members didn’t spend all of their time in a single WG. Doing 
that leads to lack insight and of trust.
•
Try to spend at least one day each meeting in a WG that isn’t “your own” 
•
Try to read several papers from each mailing that is not aimed at “your WG”
Note that if “your” proposal progressed, you’ll have to shepherd it through different WGs, so it is good 
to have some understanding of how they operate.
6.1.
Trust
At the start of the fo
rmal standardization efforts (ANSI and ISO), P.J. Plauger and Tom Plum emphasized 
the need for trust in the process.
 The 
desired degree of trust is currently missing
, and the consequences 
are dire
. 
A WG can spend meetings on a proposal, carefully craft
ing 
a compromise
,  balancing concerns, just to 
have the next WG spend several meetings reviewing the proposal, demanding changes, and rephrasing 
the wording with
 patchy understanding 
of the design rationale
 as it evolved
 over time. 
In particular
•
large feature developments should be discussed in joint EWG+CWG, LEWG+LWG, and/or 
EWG+LEWG sessions as early as the overall design and the understanding of the underlying 
implementation alternatives allows.
 Finally, after years of process, someone th
en stands up in ful
l committee and raises issues that have 
been discussed for years stat
ing 
“lack of comfort
” with the proposal
, suggesting alternative approaches,
and demanding more time to consider or rejection. At this point
,  everybody unhappy with compromises 
made along the way chirps in with counter
-points made over the years and the proposal is either 
withdrawn or defeated by a 
20% minority
, many of whom did 
not 
take part in previous discussions
. We 
think that
•
“lack of comfort” is not sufficient to block a proposal
Even
 when (as is common) there are minor remaining issues, t
ypically, there are
 many months between 
a proposal being approved (by any part of the committee) and the final standard during which non
-fatal 
flaws can be fixed. We think that a proposal that has pas
sed a committee (say EWG or LEWG) should be 
accepted without undue delays by further groups. Obviously, new inputs should be considered, but in 
the absence of 
new information
,  “we considered and discussed that” by a W
G chair should be 
conclusive:
•
People
 who were not sufficiently motivated to take part in the discussion or 
conclusively 
defeated 
in WG 
should feel obliged to at least stay neutral.
Directions for ISO C++
DWG
 P0939
r0
14
Unfortunately, this principle is easily gamed by people who break it to block proposals they don’t like. 
This h
as been observed in the committee and has led to resentment
 and erosion of trust
. 
At a first approximation,
•
No proposal is ever perfect.
•
Different people have very different ideas of what degree of perfection is needed for a proposal 
to be part of the stan
dard (or part of a TS).
“The last bug” is a common programmer’s joke and our language specification reads like a program in a 
poorly defined language (English) without advanced control structures
, without abstraction 
mechanisms, 
 and without a compiler. Co
nsequently, perfection will always elude us and we should take 
that into account when we decide what is “good enough” for a standard (or a TS).
We have seen proposal move forward with an issues list to be considered before a final vote or even 
after. We st
rongly encourage that approach to make progress
•
If a proposal is fundamentally sound
,  it should be moved forward, even into the WP text
•
Refinement of text can (and should) happen later
•
There are problems that are unlikely to be found until after the wording for a proposal is 
integrated into the WP text
 (as in software development: “integrate early to allow testing”)
•
Addition of desired but incompletely developed feature
s   can wait until later, even to a later 
standard
•
As the shipping date for a standar
d approaches, the efforts to “polish” the text and drain the 
issue lists should be redoubled at the expense of effort on new proposals
 (as is currently done)
Through delay
s,    a good proposal can get dated
,  failing to benefit from
 years improvements and progress
in the community
. Note the file system
 TS and
 networking TSs each has
 a decade of use behind them. 
Similarly
, 
std::variant
, 
std::optional
, and 
std::any
 have
 a long history as independent proposals
. That 
would
n’t
 be too bad if the reason was that 
signi
ficant improvements were added during the process
. 
However,
 the current process tends to reduce proposals to their most conservative cores. Thus, some 
“novel” C++ features feel dated by the time they are accepted.
•
Aim for prompt delivery followed by increm
ental improvements
Note that this approach can only succeed if the end
-goals are reasonably clear.
•
Articulate the end goals for a proposal
When triaging features for consideration, we propose
 that
 the 
WG 
chairs to put a higher priority on 
features that con
form to these goals, but also keep a watch against features that
•
Turn C++ into a radically different language
•
Turn parts of C++ into a much significantly different
 language by providing a segregated sub
-
language
•
Have C++ compete with every other language b
y adding as many as possible of their features
•
Incrementally modify C++ to support a whole new “
paradigm
” 
•
Hamper C++'s use for the most demanding systems programming tasks
Directions for ISO C++
DWG
 P0939
r0
15
•
Increase the complexity of C++ use for the 99% for the benefit of the 1% (us and our
 best 
friends)
The
 committee members and proposal authors are a group of volunteers who may have different aims, 
industry views, or company directives. As we propose features, we urge the group to maintain cordial 
discourse, and aim for what is best for C++ as a language and not merely what is best for your 
company
’s current
 direction. This sometimes mean
s   willing collaboration with people with different 
aims and priorities.
 For the most part, we have been successful. 
More specifically, don’t o
ppose 
a 
pro
posal
 just because:
•
it is seen as competing with your favorite proposal for time/resources 
•
it is not relevant to your current job
•
you have not personally reviewed it
•
it is not p
erfect 
(according to your principles)
•
it is not 
coming from your friends
•
it is coming from someone you have been at odds with
6.2.
Proposal processing
WG21 does not lack for proposals today. The interest is high and the number of proposals of each 
mailing grow to 
more than 100 in a mailing. That’s 
unmanageable for an individual with a d
ay job
. To 
focused on the priorities discussed in this document, we recommend that chairs focus
 at least
 60% of 
their time on advancing these priorities. How that is done is entirely the chairs prerogative.
 For example:
•
Raise the barrier for repeated
 prese
ntation of and voting on failed proposals
. 
•
Require a short
 tutorial 
for each 
proposal
For any non
-trivial proposal, it is not obvious how to use the new facility well in combination with other 
features. It is easy to say
 “teaching this is easy” but such st
atements should be backed
-up
 with examples 
and experience
 report (or be clearly marked as conjecture)
. In particular,
 for whom
 is learning and using 
a new feature easy
? 
•
Never assume that the use 
of 
a propos
ed feature is easy and obvious to everybody.
The v
olume of proposals is such that p
eople are not able to track all 
upcoming votes
. T
his has led to 
“no
” votes
 in WGs and plenary
. We ask the committee to consider process improvements 
that improve 
this communication and notification, but also ask that members actively review
 and
 discuss with others 
their proposal progress, s
o that the burden is fairly spread. At one time, Alistair Meredith did a great job 
of summarizing the flow and progress of each paper prior to C++11. Today this is unmanageable for one 
person. We have noted other forms of process improvement that has helped improved communication, 
and understanding the issues as we review papers. These include use of githubs, and sum
mary notes 
recorded for each proposal,
 to save readers the bother
 of going through each meeting minutes
 to trace 
the history of a proposal and find the related papers
. We do not necessarily enforce any particular 
methods, but feel some method should be con
sidered to allow other groups to track progress.
Remember the need for trust (
§6.1):
Directions for ISO C++
DWG
 P0939
r0
16
•
“I didn’t have time to read the document” is not sufficient
 reason to 
oppose
 (provided the paper 
was submitted on time)
•
“I don’t understand” is not by itself sufficient
 reason to 
oppose
 (give reasons and examples why 
your lack of understanding is not just your own problem)
6.3.
The role of TSs
Technical Specifications
 (TSs) have
 become popular
. In theory
,  they provide an intermediate state where 
major new features can be 
disc
ussed, specified, tested under fewer constraints than for the standard 
itself, and later be moved into the standard with changes based on the experiences gained. The move 
from a TS to an IS is supposedly simplified by the significant work to complete the T
S and the experience 
gained
. 
 In practice
, this seems to work
 reasonably 
well 
for libraries, though we see examples where facilities 
are stripped from a proposal as being too advanced, rather than pushed forward for experimentation. 
For language features, the experience is less positive. It seems that the barrier to entry into a TS is not 
significantly lower than for an IS, and the effort devoted to complete a TS detracts from 
experimentation, freezing the language feature in time years before acceptance. A
fter the TS, most of 
the design and specification issues are 
then revisited a second time. Thus, a TS becomes a method for 
delaying a proposal. Also, a TS doesn’t seem to be sufficient to encourage multiple implementations. 
This implies that large parts of 
the C++ community doesn’t get to use the facility, large organizations 
using multiple compilers can
’t  experiment with  
the TS
 at scale
, and tool builders hold back waiting
 for 
an “proper standard” supported by all major implementers. Consequently, d
etract
ors can dismiss the 
experience reports and clamor for novel 
alternatives.
We recommend
•
Use TSs for library components.
•
Don’t use TSs for a 
language feature
 unless the feature is a mostly self
-contained unit.
•
Never use a TS simply to delay; it doesn’t simpl
ify later decision making.
If a proposal isn’t ready for the standard let it be improved or rejected in the appropriate WG or SG 
(Study Group). Don’t add a formal TS process.
6.4.
“Details” 
The committee spends most of its time on details that the average programmer will never notice. A lot 
of that is necessary.
 However, it seems th
at most members spend most of their
 time on such details
; 
that’s wasteful and weakens the language as experience
d by users
. Instead
, try to spend the majority of 
time on design issues, such
 as:
•
What problems are this feature meant to solve? (D&E recommends not to accept a feature that 
doesn’t solve two apparently unrelated problems)
•
What alternative solutions are po
ssible?
•
What related features should be considered simultaneously with this one?
•
How well does this feature fit with the general style of the language and standard library?
•
Is this feature aimed only for a few language or library experts or will it be used
 in application 
code?
Directions for ISO C++
DWG
 P0939
r0
17
An individual
 proposal 
is essentially never useful in isolation, it will work in combination with other 
features:
•
Consider every feature in the context of features with which it will be 
used 
•
Don’t approve a set of related features on
e by one, evaluate them together
In particular, cluster related proposals (language and library) together.
•
Be fair when comparing alternative proposals
In particular, try hard to give discussions of advantages and disadvantages equal weight for each 
alternative. Presenting only advantages for a “favored proposal” and only “disadvantages” for an 
unfavored alternative is not acceptable.
The text of the standard should be precise and comprehensive. It is not supposed to be a tutorial, but 
the ideal is th
at after some “acclimatization” 
an experienced programmer should be able to interpret 
the text with some 
confidence. This is not currently the case. When crafting WP text
•
Consider readability by people not members of the WG crafting the text
•
Non
-normative 
notes can be useful
•
Short examples can be very useful
•
Try not to change the meaning of terms common in the C++ community
•
Where possible, use terms common in the C++ community
Remember that compiler writers and standard
-library implementers are not the only
 target audience for 
the standard (or a TS).
7.
The C+
+ Programmers
’ Bill of Rights
This note was posted to reflectors
, presented at the June 2017 Toronto meeting
 and discussed
. We 
propose that it be formally adopted by WG21:
“The C++ Programmers’ Bill of Rights
.”  
We, the ISO C++ Standards Committee, promise to deliver the following to the best of our ability, 
assuming user code adheres to the 
current standard:
1.
Compile
-time stability
: Every 
significant 
change in behavior in a new version of the standard 
is detectable by a compiler for the previous version.
2. 
Link
-time stability
: ABI breakage is avoided except in rare cases, which will be well 
documented and supported by a written rationale.
3. 
Compiler performance stability
: Changes will not imply significant added compile
-time 
costs 
for 
existing code.
4. 
Run
-time Performance stability
: Changes will not imply significant 
added run
-time costs to 
existing code.
5.
 Progress
: Every revision of the standard will offer improved support for some significant 
pro
gramming activity or community.
Directions for ISO C++
DWG
 P0939
r0
18
6. 
Simplicity
: Every revision of the standard will offer sim
plification 
for
 some significant 
programming activity.
7. 
Timeliness
: Every
 revision of the standard will be shipped on time according to a published 
schedule.
Note “to the best of our abilities”. These are 
ideals or guiding principles, rather than executable 
statements. For example, if a function
 is added
 to a header file, the compilation of code that includes 
that header will slow down imperceptibly. That’s acc
eptable
. Adding enormous amounts of code to a 
header so that compilation slow
s   noticeably would be another matte
r. 
These are ideals. They are what we would like to see done. I
f we succeed, most users will be very happy. 
However, they are not a recipe we c
ould blindly follow to deliver a new standard. As is typical for ideals, 
they can conflict: there are tensions among the desired goals. This is common: Ideally, we want quality, 
on
-time delivery, and low cost of products, but we know from vast experience that it is very hard to get 
all three. We want freedom of speech and absence of verbal intimidation, but balancing those two can 
be very hard. It is the same for the ideals of the “The C++ Bill of Rights”; we want all, but the committee 
will have to make hard choices.
These are ideals. They are meant to be rather grand statements, rather than nit-
picked long sentences
watered down by adjectives and caveats. It will be up to the committee members to interpret the ideals 
in the light of
 real design and schedu
ling problems.
There are just 7 ideals listed and they are quite general. We could add many more, but a laundry list of 
specifics would dull the appeal and be impossible to remember in the heat of discussions about 
direction, what can be delivered when, a
nd specific technical concerns.
8.
Caveat
The members of the direction group have been members of the standards committee for decades. We 
were (we think) chosen because we have deep and broad experience with the C++ technology, use, and 
community. We all have
 well documented track records. In the role of members of the direction group, 
we try to serve the good of the C++ community as a whole. It is not possible to completely separate 
what we consider best for the C++ community from the specific proposals we wo
rk on, but we try not to 
unfairly favor our own proposals
. Similarly, we try not to discourage proposals or actions just based on 
personal biases. Some of our recommendations may not be universally appreciated, but nothing we say 
is meant to insult anyone.
Some of the recommendations here could be seen as contradictory
. We see such as fundamental 
tensions in a design, requiring tradeoffs, rather than contradictions. Design is hard, design by 
committees is even harder.
9.
Acknowledgements
Many of the arguments 
and points of view have a long history in the committee. Thanks to all who 
contributed. In particular, than
ks   to the authors of the documents we reference here.