798. Refactoring of binders lead to interface breakage

Section: 99 [depr.lib.binders] Status: CD1 Submitter: Daniel Krügler Opened: 2008-02-14 Last modified: 2016-01-28 10:19:27 UTC

Priority: Not Prioritized

View all other issues in [depr.lib.binders].

View all issues with CD1 status.

Discussion:

N2521 and its earlier predecessors have moved the old binders from [lib.binders] to 99 [depr.lib.binders] thereby introducing some renaming of the template parameter names (Operation -> Fn). During this renaming process the protected data member op was also renamed to fn, which seems as an unnecessary interface breakage to me - even if this user access point is probably rarely used.

Proposed resolution:

Change [depr.lib.binder.1st]:

template <class Fn> 
class binder1st 
  : public unary_function<typename Fn::second_argument_type, 
                          typename Fn::result_type> { 
protected: 
  Fn fn op; 
  typename Fn::first_argument_type value; 
public: 
  binder1st(const Fn& x, 
            const typename Fn::first_argument_type& y); 
  typename Fn::result_type 
    operator()(const typename Fn::second_argument_type& x) const; 
  typename Fn::result_type 
    operator()(typename Fn::second_argument_type& x) const; 
};

-1- The constructor initializes fn op with x and value with y.

-2- operator() returns fnop(value,x).

Change [depr.lib.binder.2nd]:

template <class Fn> 
class binder2nd
  : public unary_function<typename Fn::first_argument_type, 
                          typename Fn::result_type> { 
protected: 
  Fn fn op; 
  typename Fn::second_argument_type value; 
public: 
  binder2nd(const Fn& x, 
            const typename Fn::second_argument_type& y); 
  typename Fn::result_type 
    operator()(const typename Fn::first_argument_type& x) const; 
  typename Fn::result_type 
    operator()(typename Fn::first_argument_type& x) const; 
};

-1- The constructor initializes fn op with x and value with y.

-2- operator() returns fnop(value,x).