Core Extensions for Evolution

Document Number: n2173(07-0033)
2007-03-09
Alisdair Meredith <alisdair.meredith@uk.renaultf1.com>

Background

A number of issues have been resolved by the Core Working Group as extension requests better addressed in a future C++ standard. These were handed over to the Evolution Working Group at the October 2002 meeting. Unfortunately it appears the EWG did not pick up these issues and I believe they have been quietly neglected for C++09. The intent of this paper is to make a hasty review of those issues to confirm that there is nothing important that must be addressed.

There are currently 10 issues with this status, so I shall try to summarise them quickly below. For each I recommend one of 3 actions:

  • Acknowledge issue is important and try to resolve it for C++09
  • Agree issue is interesting, and 'Open' it to be addressed after C++09
  • Suggest issue is not interesting enough, or can be met with other proposals - move back to Core as NAD.

    • The issues are generally on the scale of a regular defect report, and as such it is recommended that Core take care of the technical work (wording) once the EWG gives a direction.

    Linkage issues

    # 13: extern "C" fns as template params
    Recommend: resolve for C++09

    This closes a hole in the type system, and the question still comes up today. Recommend resolving in C++09, possibly with an attribute-like mechanism (see n2224 in this same mailing)

    #107: linkage of operator functions
    Recommend NAD
    #168: C linkage of static members
    Recommend: NAD

    Both have issues promoting functions out of class and into global namespace.

    Memory Management

    #220: require de-allocation not throw
    Possible link with library issues 206 and 627
    Recommend: resolve for C++09

    This should be given a clear answer for C++09, but I don't want to prejudge whether it should be yes or no.

    #256: overflow calculating size of new array
    Recommend: resolve for C++09

    This improves program correctness and robustness for minimal cost - although I have not evaluated ABI concerns.

    Template Issues

    #150: template template and default params
    Recommend: Open

    It could be interesting addition to the language, but is too late to receive suffient attention for C++09

    #229: partial specialization of function templates
    Recommend: NAD

    Most of this functionality can be offered through concept_maps, so I suggest it is not worth the effort to write such a tricky extension purely for the benefit of unconstrained templates in the future.

    Miscellaneous

    #6: enhanced support for copy ellision when inlining
    Recommend: Open

    This looks like a valid concern, but with ill-defined scope it is probably too big a change to adopt this close to the C++09 deadline.

    #294: can static_cast drop exception specs
    Recommend: NAD

    #359: Type definition inside anonymous union
    Recommend: NAD

    The functionality on offer seems minor relative to the effort involved to support it.