Sure, go ahead. But notice I'm not using the current standard to think
about your proposal. I'm just asking a direct question about your example,
in your world, to know if that is even possible to implement (efficiently)
in real life. That's a question that will be asked (and has already been
asked) by everybody.

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

>
>
>
> 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"?
> ‐-----------
> That's thinking how to use the proposal with the limitation of the current
> standard.
> Keep in mind, that with each change, there is a different way of thinking
> and usage.
>
> Just give some time, I'm writing something that looks like a paper. I'm
> certain it will make more sense and clears a lot of confusion.
>
>
> 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
>>>
>>