Re: [boost] Help! Detecting that two template aliases are equal.

Subject: Re: [boost] Help! Detecting that two template aliases are equal.
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2012-11-04 11:54:22

On Sun, Nov 4, 2012 at 1:43 AM, Jeffrey Lee Hellrung, Jr. <
jeffrey.hellrung_at_[hidden]> 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