ISO/ IEC JTC1/SC22/WG21 N1723

                                               Document number: N1723=04-0163
                                               Date: 20 Oct 2004
                                               Reply to: Matt Austern
                                                         austern@apple.com

              PROPOSED RESOLUTIONS TO LIBRARY TR ISSUES

1.4 Meaning of "impure extension"
    Remove paragraph [tr.intro.ext]/2 ("The first three categories are
    collectively ...") 

    Change [tr.tuple.pairs]/1 from:
            This is an impure extension (as defined in section 1.2) to the
            standard library class template std::pair.
    to:
            These templates are extensions to the standard library class
            template std::pair.

2.5 May smart pointers point to incomplete types?   
    Accept proposed resolution from TR issues list, N1688

2.10 Missing converting constructor requirements     
    Accept proposed resolution from TR issues list, N1688

3.12 Conversion of traits to integral_constant
3.14 Type_traits specifications could be simpler
3.15 Inconsistent non-normative note for has_virtual_destructor
    Accept proposed resolution from N1713=04-0153

3.16 aligned_storage underspecified?
    Replace [tr.meta.trans.other] paragraph 1 with:

    Preconditions: Len shall be nonzero. Align shall be equal to
    alignment_of<T>::value for some type T. 

    type: an unspecified POD type suitable for use as uninitialized
    storage for any object whose size is at most Len and whose
    alignment is a divisor of Align. 

    [Note: a typical implementation would define type as:
        union type
        {
           unsigned char __data[Len];
           /Aligner/ __align;
        };
    where /Aligner/ is the smallest POD type for which
    alignment_of</Aligner/>::value is Align. 
    -- end note.]

3.17 type_traits Compromise Requirements

    Change [tr.meta.req]/3 from:
            If there is no means by which the implementation can
            differentiate between class and union types, then the class
            templates is_class and is_union need not be provided.
    to:
            If there is no means by which the implementation can
            differentiate between class and union types, then the class
            templates is_class and is_union shall be defined as follows:
                    template <class T> struct is_class {};
                    template <class T> struct is_union {};

    Change [tr.meta.req]/4 from:
            If there is no means by which the implementation can detect
            polymorphic types, then the class template is_polymorphic need
            not be provided. 
    to:
            If there is no means by which the implementation can detect
            polymorphic types, then the class template is_polymorphic
            shall be defined as follows: 
                    template <class T> struct is_polymorphic {};

    Change [tr.meta.req]/5 from:
            If there is no means by which the implementation can detect
            abstract types, then the class template is_abstract need not
            be provided. 

    to:
            If there is no means by which the implementation can detect
            abstract types, then the class template is_abstract shall be
            defined as follows: 
                    template <class T> struct is_abstract {};

3.19 Incorrect normative description of type properties
    Accept proposed resolution from TR issues list, N1688

4.38 Seeding of random number generators

    Modify section 5.1.1 as follows:
         * In paragraph 2, add after "v is an lvalue of X"
                  ..., s is a nonnegative value of integral type, ...
         * Add in table 9 before X(g):
                 expression: X(s)
                 return type: none
                 pre/post-condition: creates an engine with the initial
                     internal state determined by s 
                 complexity: O(size of state)
         * Add in table 9 before seed(g):
                  expression: u.seed(s)
                  return type: void
                  pre/post-condition: post: sets the internal state of
                     u so that u == X(s). 
                  complexity: same as X(s)

         *  Merge paragraph 5 with paragraph 4 and remove the
            words at the beginning of paragraph 5: "For every pseudo-random
            number engine defined in this clause" so that the requirements in
            paragraph 5 become general "additional requirements". 

    In section 5.1.4.1 "linear_congruential", replace the declarations in
    both the synopsis and the detailed description: 
        explicit linear_congruential(UIntType x0 = 1);
        ...
        void seed(UIntType x0 = 1);
    by
        explicit linear_congruential(unsigned long x0 = 1);
        ...
        void seed(unsigned long x0 = 1);

    In section 5.1.4.5 "discard_block", add (also to the synopsis)

        explicit discard_block(unsigned long s) 

        Effects: Constructs a discard_block engine. To construct the subobject
        b, invokes the b(s) constructor. Sets n = 0. 

   In section 5.1.4.6 "xor_combine", add (also to the synopsis)
    
        explicit xor_combine(unsigned long s) 

        Effects: Constructs a xor_combine engine. To construct the subobject
        b1, invokes the b1(s) constructor. Then, to construct the subobject
        b2, invokes the b2(s+1) constructor. [Note: If both b1 and b2 are of
        the same type, both engines should not be initialized with the same
        seed.]  

5.2 Assoc_legendre incorrectly requires  a domain error
5.3 Assoc_legendre should require domain error when |x| > 1
5.4 Beta should have domain error if x <= 0 or y <= 0
5.5 Legendre should always have domain error if |x| > 1
5.6 Bessel should require domain error for x < 0
    Accept the proposed resolution from N1665.

5.7 Order parameter in Bessel functions should be restricted
    Accept the proposed resolution from N1697.

6.15 Hash functions and const containers
    In table 14, unordered associative container requirements, replace the
    assertion column for X::hasher with: "Hash is a unary function object
    type such that the expression hf(k) has type std::size_t".

6.16 Swap() missing from header synopses
    Accept proposed resolution from TR issues list, N1688

6.17 Hashing strings, revisited
    Accept option 1 of proposed resolution from TR issues list, N1688

7.28 What is an invalid/empty regular expression?

In [tr.re.regex.construct], change paragraph 1 from:
	Effects: Constructs an object of class basic_regex. The
	postconditions of this function are indicated in Table 19.
to:
	Effects: Constructs an object of class basic_regex that does
	not match any character sequence.

Remove Table 19.

In the declaration of basic_regex in [tr.re.regex], change:
	// capacity
	bool empty() const;
	unsigned mark_count() const;
to:
	// capacity
	unsigned mark_count() const;


Remove the entry for empty() in the following tables:
	Table 20 [basic_regex(const charT* p, flag_type f) effects]
	Table 21 [basic_regex(const charT* p1, size_type len, flag_type f) effects]
	Table 22 [basic_regex(const basic_regex& e) effects]
	Table 23 [basic_regex(const basic_string&) effects]
	Table 24 [basic_regex(ForwardIterator first, ForwardIterator last,
		              flag_type f, const Allocator&) effects]
	Table 25 [basic_regex& assign(const basic_string<charT, string_traits, A>& s,
		                      flag_type f) effects]

[Also, the title of Table 24 still mentions an Allocator argument, which should
have been removed in a previous edit]


Change the last sentence of [tr.re.regex.locale]/1 from:
	Calls to imbue invalidate any currently contained regular
	expression.
to:
	After a call to imbue the basic_regex object does not match
	any character sequence.

Remove [tr.re.regex.locale]/2, which reads:
	Postcondition: empty() == true.

7.34 Meaning of the match_partial flag
    Remove match_partial.

7.54 Format_no_copy specified incorrectly
    Accept proposed resolution from TR issues list, N1688

7.55 typo in  regex_token_iterator::operator++
    Accept proposed resolution from TR issues list, N1688

7.56 match_results stream inserter not  specified
    Add the specification of nonmember swap as proposed in the TR
    issues list, N1688, but remove the stream inserter.

7.57 imprecise specification of match_results::size()

    In [tr.re.results.size] (7.10.2), change the Returns clause for
    the size member function from "Returns: One plus the number of
    marked sub-expressions in the regular expression that was
    matched." to "Returns: One plus the number of marked
    sub-expressions in the regular expression that was matched if
    *this represents the result of a successful match.  Otherwise
    returns 0. [Note: The state of a match_results object can be
    modified only by passing that object to regex_match or
    regex_search.  Sections tr.re.alg.match and tr.re.alg.search
    specify the effects of those algorithms on their match_results
    arguments.]"

    In tr.re.alg.match (7.11.2) paragraph 3, change "the effect on
    parameter m is unspecified" to "the effect on parameter m is
    unspecified except that m.size() returns 0 and m.empty() returns true"

    In tr.re.alg.search (7.11.3) paragraph 3, change "the effect on
    parameter m is unspecified" to "the effect on parameter m is
    unspecified except that m.size() returns 0 and m.empty() returns true"

7.58 Does match_results<>::begin() point to element 0
    In the description of match_results<>::begin() and
    match_results<>::end in 7.10.3, change "enumerates over all the marked
    sub-expression matches stored in *this" to "enumerates over all the
    sub-expressions stored in *this".

7.59 "Implementation defined" in regex traits requirements
    Accept proposed resolution from TR issues list, N1688

7.60 Requirements for v.isctype in regular expression traits
    In [tr.re.req] (7.3) paragraph 4, add "cl is an object of type
    X::char_class_type". In table 15, change the expression "v.isctype(c,
    v.lookup_classname(F1, F2))" to "v.isctype(c, cl)" and change the
    note to "Returns true if character c is a member of one of the 
    character classes designated by cl, false otherwise".

7.61 Definition of match_results::position
    In 7.10.3 change the definition of position from 
         Returns: std::distance(prefix().first, (*this)[sub].first).
    to     
         Returns: The distance from the start of the target sequence
         to (*this)[sub].first. 

7.62 Is regex_traits::size_type necessary?
    Remove size_type from the regex trait requirements table (table 15)
    and from class template regex_traits (tr.re.traits, 7.7).  In 
    both places, change the return type of length() to std::size_t.

7.63 effects clause of regex algorithms and match_partial
    In the description of regex_match, change "Determines whether
    there is an exact match" to "Determines whether there is a
    match".

7.64 exception safety of assign(basic_string<>)
    In the description of basic_regex::assign(string), add a note
    saying that if assign throws then *this is unchanged.

7.65 We still have str() in basic_regex::assign
    In 7.8.2/13 change "returns the result of assign(e.str(), e.flags())"
    to "returns the result of assign(e)". 

    In 7.8.4/1, change "Returns assign(that.str(), that.flags())" to
    "Copies that into *this and returns *this."  Create a table to 
    reflect the result of that operation, modeled on the copy 
    constructor table.

10.4 Argument passing for reference_wrapper::operator()
    Accept proposed resolution from TR issues list, N1688

10.8 Class template function should have null pointer assignment/
             comparison operations 
    Accept proposed resolution from TR issues list, N1688
    [Note to editor: remove the spurious allocator argument.]

10.10 result_of should be based on rvalues, not lvalue
    Accept proposed resolution from TR issues list, N1688

10.19 Underspecification of reference wrapper assignment
    In the reference_wrapper summary 2.1.2 [tr.util.refwrp.refwrp], replace:

      // construct/copy/destruct
      explicit reference_wrapper(T&);

    With the following:

      // constructors
      explicit reference_wrapper(T&);
      reference_wrapper(const reference_wrapper<T>& x);

      // assignment
      reference_wrapper& operator=(const reference_wrapper<T>& x);

    In 2.1.2.1 [tr.util.refwrp.const], after paragraph 2, add:

      reference_wrapper(const reference_wrapper<T>& x);

    3   Postconditions: *this references the object that x references.
    4   Throws: Does not throw.

    Add a new section 2.1.2.2 [tr.util.refwrp.assign] after section
    2.1.2.1 [tr.util.refwrp.const], containing:  

      reference_wrapper& operator=(const reference_wrapper<T>& x);

    1   Postconditions: *this references the object that x references.
    2   Throws: Does not throw.

10.24 Mem_fn result_type for pointer to data member
    Remove result_type for pointer-to-data-member.

10.26 Wrong arguments to unary_function and binary_function
    Accept proposed resolution from TR issues list, N1688

10.27 Reference_wrapper should be in <functional>
    Accept proposed resolution from TR issues list, N1688

10.29 reference_wrapper<reference_wrapper<T> >
    Accept proposed resolution from TR issues list, N1688,
    but only the parts changing the behavior of ref and 
    cref, not the parts that make nested reference_wrapper
    ill formed.

10.30 function comparison operators unreliable
    Accept proposed resolution from TR issues list, N1688

10.32 function(reference_wrapper f) targets f.get
    Accept proposed resolution from TR issues list, N1688

10.34 is reference_wrapper<void()> supposed to be legal?
    In the proposed resolution in N1673, replace the first bullet in the
    definition of *simple call wrapper* from:

      - if T is a pointer to function, result_type shall be a synonym for
        the return type of T; 

    to the following:

      - if T is a function, reference to function, or pointer to function
        type, result_type shall be a synonym for the return type of T;

10.35 result_of and Standard Library Function Objects
    Change the beginning of the first sentence of [tr.func.ret]/3 from:
        If the implementation cannot determine the type of the expression
        f(t1, t2, ..., tN), or if the expression is ill-formed, the
        implementation shall use the following process to determine the
        member type type:
    to:
        If F is not a function object defined by the standard library, and
        if either the implementation cannot determine the type of the 
        expression f(t1, t2, ..., tN) or else if the expression is ill-formed,
        the implementation shall use the following process to determine the
        member type type:
    Remove bullet item 3 from [tr.func.ret]/3.

10.37 TR1Function Objects and Backward Compatibility

    In the revised version of [tr.func.memfn], add the following after the
    "Returns:" paragraph:

        The simple call wrapper shall be derived from
        std::unary_function<cv T*, R> when pm is a pointer to member
        function with cv-qualifier cv and taking no arguments.

        The simple call wrapper shall be derived from
        std::binary_function<cv T*, T1, R> when pm is a pointer to
        member function with cv-qualifier cv and taking one argument
        of type T1.

    Change the first line of the declaration of reference_wrapper in
    [tr.util.refwrp.refwrp] from:
        template <class T> class reference_wrapper {
    to:
        template <class T> class reference_wrapper
                : public unary_function<T1, R>          // see below
                : public binary_function<T1, T2, R>     // see below
                {

    Add the following text immediately before [tr.util.refwrp.const]:
        The template instantiation reference_wrapper<T> shall be derived 
        from unary_function<T1, R> only if the type T is any of the 
        following:
                -- a function type or a pointer to function type taking
                   one argument of type T1 and returning R 
                -- a pointer to member function type with cv-qualifier cv 
                   and no arguments; the type T1 is cv T* and R is
                   the return type of the pointer to member function
                -- a class type that is derived from unary_function<T1, R>

        The template instantiation reference_wrapper<T> shall be
        derived from binary_function<T1, T2, R> only if the type T
        is any of the following: 
                -- a function type or a pointer to function type taking
                   two arguments of types T1 and T2 and returning R 
                -- a pointer to member function with cv-qualifier cv
                   and taking one argument of type T2; the type T1 is
                   cv T* and R is the return type of the pointer to
                   member function 
                -- a class type that is derived from
                   binary_function<T1, T2, R> 

10.38 Accessing the target of a TR1 function object
    Accept the proposed resolution from N1667, but renaming type to
    target_type, and returning the type_info by const reference instead
    of by value. 

11.4 "ignore" unspecified
    Accept proposed resolution from TR issues list, N1688

11.5 Tuple inequality tests badly specified 
    In sections 6.1.2.5, 6.1.2.6, and 6.1.2.7, rewrite the
    descriptions of operator!=, operator>, operator<=, and operator>=
    in terms of operator== and operator<.

11.7 Tuple interface to pair and array: which header?
    Accept proposed resolution from TR issues list, N1688

11.2/11.3/11.6
    Remove tuple I/O from tr1.