ISO/ IEC JTC1/SC22/WG21 N1364

        Doc No: SC22/WG21/N1364
                J16/02-0022
        Date:   May 2, 2002
        Project:        JTC1.22.32
        Reply to:       Herb Sutter
                Microsoft Corp.
                1 Microsoft Way
                Redmond WA USA 98052-6399
                Fax: +1-928-438-4456
                Email: hsutter@acm.org

Evolution WG Proposal Skeleton
Please remove this introduction and use the template starting on the next page. (If you use this Word document directly, please update the headers too.)

Continued on next page...
        Doc No: SC22/WG21/N????
                J16/0?-????
        Date:   <date>
        Project:        JTC1.22.32
        Reply to:       <your name>
                <your company>
                <your contact info>

Your Title Here

1.  The Problem
What is the problem (not a language feature name) that you're solving? (Example: "Add support for operator.() which is missing" is not a problem, it's a proposed new language feature; instead, "support proxy objects" is a problem, even if the rest of the paper talks about operator.(). Example: "Add support for lamba expressions" is not a problem, it's a language/library feature; instead, "support providing code locally" is a problem, even if the rest of the paper talks about lamba function simulation.)
Why is the problem important? Whom does it affect? What are the consequences of not addressing it? How are people addressing, or working around, the problem today?
Which of the categories that we're interested in addressing does this fit into? The major initial categories are:
* improve support for systems programming
* improve support for library building
* improve support for generic programming
* improve compatibility with C
* make C++ easier to teach and learn
* features from other languages (but remember to state the problem being solved, not just the feature)
* remove embarrassments

2. The Proposal
2.1 Basic Cases
Give simple examples of the solution/feature. These should be enough to give the reader a basic sense of what is intended. (Example: if proposing typedef templates, show the basic use cases and syntax, and describe the semantic effects including what the feature does and what it does not do (e.g., "does not introduce a new type").)

2.2 Advanced Cases
Give more difficult cases. These should be enough to cover important corner/edge cases. (Example: if proposing typedef templates, show whether and how we would partially specialize them.)

3. Interactions and Implementability
3.1 Interactions
Describe interactions with the rest of the language.
How does the proposed feature fit with the rest of the language? (Example: syntax, semantics.)
Defend why is this not a one-off or special-purpose feature? (Example: What problems can you solve better using a combination of this feature with other existing feature(s) than you could solve using this feature or other features individually?)
Describe how the proposed feature works when you apply existing language features to it. (Example: if proposing typedef templates, show how applying something like template template parameters (an existing language features) to a typedef template.)
Describe how existing language features work when you apply the proposed feature to them. (Example: if proposing typedef templates, show how using a specialization of the typedef as a function parameter type, which could affect/improve whether the parameters' types are deducible.)
Related issue: Describe the effects on legacy code, if any. If the feature could change the meaning of legacy code, what kinds of existing code are affected, and in what way?

3.2 Implementability
Describe known and anticipated difficulties in implementing this feature.