Look at the for-loop. That's all you need to show why this doesn't work:

 for(const aut& elem: vec)
{
    auto r = elem(0);
}

Suppose you managed to make the operator() work and return different types
depending on the value of "elem".
What size of stack should be allocated for r? What destructor should be
called for "r"?






On Wed, Jul 31, 2024 at 7:46 AM organicoman <organicoman_at_[hidden]> wrote:

>
>
>
> 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_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
>>
>