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);

}

-------------

In my example i've wrote the following (copy/paste)

template<typename T>

void AcfBasedOnType(T t) { // do something }

But i get Tiago's confusion.

So let me rephrase both your concerns.

Given the definition of the call operator in struct A

auto A::operator()(int);

To deduce the auto type, compiler needs one and only one return type, otherwise compiler error.

That's what he meant to say.

I give him that, it was my mistake in writing the code, i should have wrote:

template<typename T>

T operator()(int)

{

using Ret = std::extract_1st_templ_type_t<effective_decltype(m_memFun)>;

std::any_cast<Ret>( m_memFun() );

}

Correct definition of the call operator.

I guess it fixes the problem now. Right !

You should have guessed that from the signature of the function template AcfBasedOnType

The examples i give, take them with a "soupçon" of correctness, because my goal is to demonstrate the math logic behind the proposal not how to use it.

You are all C++ expert coders and you can correct my code better than myself .. 😂

On Wed, Jul 31, 2024 at 6:21 AM organicoman via Std-Proposals <std-proposals@lists.isocpp.org> 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@yahoo.fr>
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@lists.isocpp.org>;
CC: Sebastian Wittmeier <wittmeier@projectalpha.org>;

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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals