Geometry Boost List: Re: [geometry] Run-Time specified geometries

Subject: Re: [geometry] Run-Time specified geometries
From: Samuel Debionne (samuel.debionne_at_[hidden])
Date: 2013-11-04 09:49:17

Hello Bruno,

Thank you for the detailed explanations of the "multi stage process" of
algorithms. I guess "variant resolution" means applying a visitor ?

> It's not a runtime error, as variant types are a compile time
> information. Applying the multi stage resolution as described above will
> automatically reject any variant that could possibly result in trying to
> compute the distance between a 2D and a 3G geometry - e.g. passing
> instances of variant<point<double, 2>, point<double, 3> > in parameters
> for distance will result in a compile time error. One might argue it's
> too conservative, as at run-time we won't necessarily end up asking for
> the fatal combination. But I want to leverage variants type safety as
> much as possible.

Well I could be the first one to argue that it's too conservative ! At
least for my use case. My variant is populated by all the OGC types,
that is all the combinations (points, multilines, ...) * (xy, xyz, xym,
xyzm). I can't not think of a way to reduce this set to the acceptable
combinations for each algorithms, so believe I'll will have to deal with
runtime errors at the "default strategy resolution" stage, right ?

>     Does that mean that we can dispatch incompatible variant to a runtime
>     error using not_yet_implemented ? That would be brilliant !
> 
> Again, we go conservative here. Passing variants that could result in
> computing a not yet implemented operation will result in a compile time
> error.

Could the use of a "policy" to choose between the conservative (compile
time error) and the relaxed (runtime error) approaches be an option ? Or
do you think that the relaxed approach should be built on top of the
conservative one ? Anyhow this may affect the way the support of variant
is implemented...

Samuel