Let me try to restate the flaw in a more direct way:

Take this part of the example:
 for(const aut& elem: vec)
       ActBasedOnType(elem(0));

To make it more clear, you can rewrite it as:
 for(const aut& elem: vec)
{
    auto r = elem(0);
    ActBasedOnType(r);
}

If I understand things correctly, you mean to say that depending on the
value of elem (meaning, to which function it's pointing to), we could have
a different return type (type of r).

How should the compiler implement the body of that for loop?
It needs to create the stack space for "r", but it could be different
types. How much space should it use? It needs to destroy "r" at the end of
the body, which destructor should it call?

If the compiler knew for which types you instantiated that template at
compile time (which it doesn't because that can happen across multiple
translation units), then it would have to create the code for the body
multiple times, one for each type and create a big if-else cascade.
Is that what you are proposing?

Best Regards,
Breno G.

On Wed, Jul 31, 2024 at 6:21 AM organicoman via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
>
>
> Sent from my Galaxy
>
>
>
> You have been the one who wanted to different types with decltype and
> effective_decltype.
>
>
>
> Why are you complaining?
>
> The correct answer in your example must be in the following form:
>
> // one plausible mangled name
>
> PFvvE_i <--- f<int>
>
> PFvvE_d <--- f<double>
>
> the radix PFvvE is the same denoting the same apparent type, and
> different tags { _i, _d }, to denote the effective type.
>
> Likewise, the type information is not lost. And you can trace back to what
> you have called.
>
>
> Anyway, I think we touched everything in this thread, and thanks to you
> and Tiago i found a corner case, but solved it.
>
> I think it is time to compile some wording and post it here, maybe it will
> be more clear.
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* organicoman <organicoman_at_[hidden]>
> *Gesendet:* Mi 31.07.2024 10:50
> *Betreff:* Re: [std-proposals] Function overload set type information loss
> *An:* Sebastian Wittmeier via Std-Proposals <
> std-proposals_at_[hidden]>;
> *CC:* Sebastian Wittmeier <wittmeier_at_[hidden]>;
>
>
>
> With function pointers you can achieve something like; in most cases even
> this is only possible at runtime:
>
>
>
>
>
> PFvvE <--| do you see the problem here
> PFvvE <--| f<int>,f<double>, yet the same name
> Just one function f.
> Just one function f.
> f<double>
> f<int>
> In "type theory" that's not correct.
> Two entity of different signature must have
> different types. Otherwise a many to one
> relationship takes place.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>