pt., 2 sie 2024 o 02:01 organicoman via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
>
>
>
>
> Sent from my Galaxy
>
>
>
>
> But you have yet to tell us why we need this.
>
> Can you give an example of where it would be useful? Can you compare to how
> the same problem would be solved today without the feature? How about in C++26
> with reflection, assuming reflection can solve the problem?
>




> First of all,
> The popular way of implementing reflection, is not safe at all.
> It's like you are shipping your binary with all the debug information available.
> Add on top of it, C++ UB superpowers, and it becomes lethal.
>

This shows you do not read replays. You do not have an idea how
reflection works in C++
and critique it that will not work? Again reflections is compile time
ONLY and have NO UB.


> Second of all,
> I'm still stuck in C++17, by choice.
> So if this proposal or a similar is already implemented somehow, then I'm sorry, because i didn't know.
>

And you what change C++ even if you by choice do not use the latest
version of C++?
To even suggest any change to C++ (especially so fundamental as yours) you NEED
to know current and future state C++. Why? Because what will happen when you
try to change something that will be removed from C++?


> Again, my motivation was simple, just keep every peace of information available.
>
> But when i started developing the idea, it was a lightning strike.
>
> Making the compiler create variants and code using it, ad hoc, was amazing. Because the compiler has information about all the types available in the program, yet we cannot query them.
>
> Honestly, i don't know the extent of the benefits of this proposal, I'm still discovering it with you all.
>
> But one use case that comes to my mind right now, is signal and slots.
>
> Usually we implement slots as function returning void, but in real life, slots can return anything.
> So what if i need to use the return values of a series of slots connected to a signal?
> Don't tell me use std::any...
> Because if you want to read data from that std::any you need to know what type you should cast it to, because slots are of arbitrary return type.
>
> For example:
> Signal. Slots
> int(*)(int, double)
> void(*)(int,double) char(*)(int,double)
> struct S (*)(int, double)
>
> If you collect arbitrary slots in a container, they have to get the same type
>
> vector<??(*)(int, double)>
>
> If you replace ??<-> std::any, so in a loop how will you process that data?
> How will switch based on the return type of the slot?
> To what are you going to cast that std::any?
>
> Because of this, most implementation of signal and slots throw away the slots return value.
>
> That's one example on top of my head.
>

Ok, now we are talking, but how exactly will your proposal handle it?
Because in any of yours examples you show, it can't even remotely handle it.
Even if you had some magic that knows the return type, what would you
do with the returned value?
Each type should have unique handing and need to be fully known on the
call site.
And if it is known on the call site you can handle it by `std::any`.


> The fun about this proposal, is the idea of inventing a compiler planner, that can prove at compile time what to generate.
> When to unroll a loop?
> When to stamp a switch function?
> How to consolidate different generated functions?
> ...and so on.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals