Re: [boost] Re: Shades, swap or whatever

From: Alan Griffiths (boost_at_[hidden])
Date: 2000-11-05 05:55:27

The switch to boost caught me away from the list, so I'm attempting a
summary/commentary rather than responding to specific points...

We are agreed that there is a problem, and that the standards committee
need to:

  o provide advice for implementors of (non-standard) libraries 
  o potentially make changes to the core language
  o potentially relax restrictions on user code in std

There are three approaches that have been discussed:

/1/ Cast a shadow

    Identify some set of (function template?) names, impose
    requirements on their semantics across all namespaces, and
    give the advice to always structure code so as to ensure that
    Koenig lookup brings these into the overload set.  (This advice
    also needs to be followed by implementors.)

Although this mirrors best practice with the overloading of operators I
can confidently predict that it will break code.  It doesn't allow for
future development of the library by extending the set of names, and it
leads to consumer code that is fragile.

/2/ Allow overloading

    Allow users to overload some set of function names within
    namespace std.

In the original discussion John Maddock's posted something like the
following where introducing an overload breaks what is now conforming
code:

    namespace std { 
        template<typename T> 
        ::arg::example<T> use_facet(const locale&);
    }

    void foo()
    {
       std::use_facet<int>(std::locale());  // ambiguous
    }

Scenarios where this breaks existing code are probably rare - and won't
be silent.

However Peter Dimov has recently indicated the fragility of the approach
(including the following example):

    #include <set>  // Presumably <algorithm> intended - AG

    struct base {};

    namespace std { void swap(base &, base &); }

    struct derived {};

    void f()
    {
        derived d1, d2;
        std::swap(d1, d2);
    }

This certainly makes the point that it is for a C++ user to break things
using this mechanism (even if library vendors are aware of the
pitfalls).

Another difficulty comes when developing generic components:

    #include <algorithm>
    #include <vector>

    template<
        typename Container,
        template<typename RAIterator, class Compare>
    void Sort(RAIterator first, RAIterator last, Compare comp)>
    void g(Container& c);

    void f()
    {
         typedef std::vector<int> vector;
         vector v;

         g<vector, std::sort>(v);
    }

If std::sort is overloaded then it becomes impossible to supply it as a
template parameter to g.  (IIRC Andrei Alexandrescu posted several
variations on this theme on c.l.c++.m)

With the perspective of time and recent postings I'm coming to the
opinion that allowing function templates from a single namespace to
compete in overload resolution is probably a design error.  (Naturally,
because the current language definition lacks alternatives, one may be
forced to do this - and we may be 'locked in' to this solution by prior
art in the standard library.)

/3/ Allow partial specialisation of function templates

    http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#229

    (Dave Abrahams relates that there are some ambiguity problems with
    the proposal made to the core group - but I don't see why.)

Assuming that such implementation issues are resolvable this cannot
introduce *new* problems.  This is easy to show:

    In any program an explicit partial specialisation will only be
    applied to a finite set of specific types.  If the partial
    specialisation is replaced with full specifications for each of
    these types the meaning of the program is obviously unchanged.

    (I did a maths degree and this reminds me of formal systems of
    logic in which it is possible to show there is a proof for any
    specific member of a family of theorems but not to deduce from
    this that it true for all members of the family.)

Peter's examples do highlight a need for care - but that is inherent to
the existing language.  Also, given the demonstrable fragility of the
other approaches that clearly doesn't rule this solution out.
-- 
Alan Griffiths  (alan_at_[hidden])  http://www.octopull.demon.co.uk/
ACCU Chairman   (chair_at_[hidden])             http://www.accu.org/