
On 7/10/06, Peter Dimov <pdimov@mmltd.net> 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