śr., 31 lip 2024 o 12:46 organicoman via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
...
> 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 .. 😂
>
>

Problem is that you try to break C++ type system.

You suggest:
```
"PFvvE_d" == typeid(f<double>).name()
```

And this same by analogy:

```
"i_42" == typeid(42).name()
```

Why only template parameters are propagated, not function `f` itself too?
I even recall that Rust does something like this, each function has
its own type that is
inheriting from type based on this function signature
(thanks this you can still have function pointers).

Besides your suggestion that `auto x` can propagate more than normal
type and value
is DoA as it would be breaking change, consider this simple code:

```
template<typename T>
void foo() { }

void foo2() { }

int bar(auto f)
{
    static int i = 0;
    return ++i;
}

int main()
{
    bar(&foo2);
    bar(&foo<int>);
    bar(&foo<double>);
    bar(&foo<float>);
    return bar(&foo<long>);
}
```

It needs to return `5`. And because of this you can't do any magic in
`bar` to extract additional
information from `f` argument even if the compiler knows it as it
would be an ODR violation.

>
> 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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals