Re: [boost] [result_of] result template in case of ambiguity

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2006-07-10 13:39:55

On 7/10/06, Peter Dimov <pdimov_at_[hidden]> wrote:
>
> Do you have a specific scenario in mind?
>

Yes. For clarity, it is clear that result_of< Type >::type should be
ill-formed with ambiguity, however, should result_of< Type > be instantiable
at all when the function call would be ill-formed? In short, I don't see any
mention of how instantiations of result_of should behave, I only see mention
of when accessing the nested typedef of a result_of instantiation is
ill-formed.
I guess I should follow what a basic typeof implementation would likely do
and yield an error upon instantiation of the template, but I figured I'd ask
anyway. To me it seems as though simply not defining the type typedef
could possibly be a better approach.

My exact situation is that I have a macro which I use for creating
complex, potentially overloaded function objects, which also add other
functionality necessary for models of concepts my library. The return type,
signature, and template parameters for all overloads are all passed into the
macro, and the macro automatically generates a nested result template in the
process of creating the overall function object. This result template does
not rely on any explicit typeof functionality, but rather, it uses the
overload information passed to the macro to create dummy
static functions and templates representing each overload allowable by
the current qualification, giving
each a different size return type, and using the size of the return type
when passed arguments of the given type
to determine which overload would be called. The nested type typedef is then
set to the return type of the appropriate overload.

With this implementation, I would get an error if the call were ambiguous
when the person merely instantiates result (not even trying to access the
typedef). Another alternative is that I individually check the overloads and
if multiple non-template overloads may be called and there are no template
overloads which may be called (or any other combination which results in an
ambiguous function call), then I inherit from an empty base, otherwise I
inherit from a base which yields the result type in a type typedef using the
code I described
earlier. Note that this form only produces error if you attempt to
access ::type with an ambiguous call, not if you merely instantiate
the template.

I see different advantages to each approach. With error upon instantiation,
you'd likely be getting similar functionality to a simple typeof-style
implementation, however, this gives you an error if you simply do something
such as work with a type which inherits from the instantiation, regardless
of whether or not you actually access the result.

-- 
-Matt Calabrese