On Sun, Nov 4, 2012 at 1:43 AM, Jeffrey Lee Hellrung, Jr. < jeffrey.hellrung@gmail.com> wrote:
I don't really know what you're trying to do, so this might be a completely irrelevant suggestion, but can you do something that would take advantage of, say, ambiguous overloads or ill-defined overloads if you renamed bar_alias to bar, and maybe add some dummy parameter (e.g., "...")?
No, that's a very good suggestion, and I do something similar during concept map look-up to determine and report ambiguities, but unfortunately I don't think it can be made to work here (the point that the concept map itself is written and implicit maps are generated). There are two problems: first, the ambiguity can only be detected when such a function is attempted to be called, and in order to call it, I need to be able to pass template arguments to the template in question, but for reasons mentioned earlier, this isn't technically feasible. It works during concept map look-up because at that point someone has specified a concept along with its arguments. Once archetypes are in, I might be able to hack something together, but I'm not there yet. The other problem is, I might be able to detect that the call is ambiguous, but unless I'm mistaken, I won't be able to differentiate between the overloads being effectively the same or just being ambiguous in another manner (I.E. imagine two overloads, one involving concept_map concept_< int, T > and another involving concept_map concept_< T, int >, both implicitly generated by the same more-refined concept_map). I need to make this differentiation because a general ambiguity should be ignored at the time that the concept map is written, whereas them being exactly the same is acceptable in the case that they are automatically generated -- I just need to do compatibility checking on the corresponding concept maps involved. I guess one thing that I can do is delay all checking of this kind until concept map look-up and allow ALL forms of ambiguity, doing compatibility checking on them just like I would for concept maps that should be the "same". This would at least allow valid code to compile but would just also allow some invalid code to compile as well. The only other down-side I see is that it would likely slow down compile-times since it effectively means that I may be frequently generating redundant implicit concept maps hooks behind the scenes and considering them all during look-up rather than inhibiting the creation of redundant implicit concept maps at the point they'd be created. Anyway, I don't know how clear any of that was or if I'm just too into this project to be able to communicate properly, but I think I'm just going to go this route for now unless someone has a better solution. -- -Matt Calabrese