Hi Bruno, hi Samuel. I am continuing in email.

I saw the updated version of the PR. Many thanks Samuel for making the 
changes.

There are a couple of issues that I would like to see and also hear 
opinions of others if any:
* What about the issue of not implementing variant support for 
distance(g1, g2, strategy)? As I said I do not like the idea of 
supporting passing a strategy that is completed disregarded.
* In the unit test, I would like to see the variant defined as 
variant<point, box, segment> and then try computing the distance for two 
of those for the various choices of the geometries, like you do in the 
current test. I like the idea of passing the coordinate type as 
parameter and testing for both double and int.

See also below.

On 16/05/2014 06:59 ??, brunolalande wrote:
>
> In include/boost/geometry/algorithms/distance.hpp:
>
> > +        return dispatch::distance<Geometry1, Geometry2, Strategy>::apply(geometry1, geometry2, strategy);
> > +    }
> > +
> > +    template <typename Geometry1, typename Geometry2>
> > +    static inline typename result_of::distance<Geometry1, Geometry2, default_strategy>::type
> > +    apply(Geometry1 const& geometry1, Geometry2 const& geometry2, default_strategy)
> > +    {
> > +        typedef typename detail::distance::default_strategy
> > +            <
> > +                Geometry1, Geometry2
> > +            >::type strategy_type;
> > +
> > +        return dispatch::distance<Geometry1, Geometry2>::apply(geometry1, geometry2, strategy_type());
> > +    }
> > +};
> > +
> [responding directly here as I can't see your comment on the github UI]
> I do not particularly like the idea of having two static apply methods 
> in the same class here. I would expect to see here to see the distance 
> struct templated by Geometry1, Geometry2, Strategy and then 
> specialized for default_strategy.
> Samuel follows what I've done in all other algorithms, and I prefer to 
> stick to that for consistency. That's crucial to later refactor the 
> whole thing. Also, experience in BG has proven that template 
> parameters are always better at method level than class level - 
> whenever you have the choice, you should always choose the former. In 
> this particular case I really don't see the problem of having 2 or 
> more apply methods, and I certainly don't want to move anything at 
> class level if it's not needed. Regards Bruno

Okay Bruno. That makes sense. I have to admit I did not look at how you 
implemented variant support for other algorithms.
So it is perfectly okay for me to follow Bruno's design.

Best,

- m.

> ---
> Reply to this email directly or view it on GitHub 
> <https://github.com/boostorg/geometry/pull/26/files#r12745740>.
>