// (C) Copyright 2008-2009 SDML (www.sdml.info)
//
// Use, modification and distribution is subject to the Boost Software
// License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at
// http://www.boost.org/LICENSE_1_0.txt)


// Can we use the concept stuff to descriminate between overloads. Sure, but
// it's not as easy as we'd like it to be,

// TODO: This won't actually compile!

// An ideal example of the problem may end up looking something like this.

// Finds in an arbitrary sequence
template <
    typename R, typename T,
    typename = typename concept_enabled<Range<R>>::type>
typename Range<C>::traits::iterator
find(R r, T const& x) {
    return std::find(begin(r), end(r), x);
}

// Finds using an associative container.
template <
    typename C, typename T,
    typename = typename concept_enabled<AssociativeContainer<C>>::type
typename AssociativeContainer<C>::traits::iterator
find(C& c, T const& x) {
    return c.find(x);
}

// This is trivially solved if there is iff Range<R> OR AssociateContainer<C>,
// exclusively (i.e., it can't be both). Can we FORCE the find algorithm to
// use one or the other. Sure, we could explitly specify the selection by
// creating an adaptor and a fake concept map.

// Basically the problem boils down to one of overlap. There

int main()
{
}