Hi Samuel,

Sorry for the big delay in answering this.

Variants are not geometries and are "resolved" very early in the
algorithm stages so that the penalty of using type erasure remains low.
In the other hand, any_point would be a geometry and a direct
replacement of an other model. But it would not be able to hold several
types that implement different concepts (while variant can).

Yep, I would agree with such a use of Boost.Variant to implement any_point, and yes, unlike variants this one could be considered a geometry as the underlying concept is known at compile-time.

> I've been thinking for very long about using algorithm tags to
> identify our algorithms and give them specific characteristics which
> could then be used in many ways. What you are proposing is one of
> the possible usages. So yes, the approach could make sense.

Good to hear that you had a similar idea. What other applications of
algorithm tags do you have in mind ?

Algorithms would declare their characteristics in an aspect-oriented way: arity, which input params are variant-able, what's the default result type, default strategy, which input-params are commutative, and so on. With this + the actual per-type implementation, you would have nothing else to write to spawn an algorithm. All the boiler plate stuff that currently happens in the multi-stage dispatching (variant handling, commutation, handling, etc.) would be generated for you by the Boost.Geometry framework (which of course would be the tricky part to write).

In the prototype I mention in the origin post, there is more that just
deciding if a not yet implemented (nyi) algorithm should static assert
or throw. It also requires that every single nyi feature to compile,
that is even for inapplicable type combinations. For that, a fake
implementation should be provided for algorithms but also for
intermediate results (see not_implemented_result_handler). While my
solution works it requires to inspect and fix every algorithm/strategy
implementation. Do you have any idea how to solve this problem with a
less intrusive solution ?

This is why we first need to have algorithms declare themselves in the way I'm describing above. I see this as the building block to many things.

Moreover, I think I was quite lucky to pick the within algorithm as an
example, intersection would have been much more challenging since the
result type depends on the input types. It would be nice if such
algorithm expose a meta function to compute the result type...

It's always difficult to choose whether to start from the easiest or the hardest. For variant I chose the former approaches as I was fairly confident there would be no showstopper with the more sophisticated algos. For this one I think whatever solution you come up with should be validated with the most complicated algo before the first commit, just to check feasibility.

Regards

Bruno