pt., 2 sie 2024 o 16:16 organicoman <organicoman_at_[hidden]> napisał(a):
>
>
>
>
>
> Sent from my Galaxy
>
>
>
>
> here: "The popular way of implementing reflection, is not safe at all"
> and here: "and it becomes lethal"
> C++ reflections is not a "popular" solution, quite the opposite.
> At least Nothing like C# or Java reflection.
>


> My sentences are very clear,
> C++ reflection is still a proposal, the other languages (as you mentioned) use implementations that are not safe.
> But it's ok, since they are not meant to be used in critical softwares like C++.
>

And you compare your proposal to C++ reflection or "other reflections"?
And is not "proposal", it very coles to be standard:
https://herbsutter.com/2024/07/02/trip-report-summer-iso-c-standards-meeting-st-louis-mo-usa/
Beside there is available for long time in experimental branch:
https://godbolt.org/z/zW9aMx8qM

```
constexpr auto r = ^int;
typename[:r:] x = 42; // Same as: int x = 42;
typename[:^char:] c = '*'; // Same as: char c = '*';

int main()
{

}
```

Did you read this paper at least once? Or is this too much to ask you?


> If you can't even spend time to read one papare to get familiar to C++
> reflection then is mean your goal is waste every one time here as you
> simply ignore all replies to your claims.
> I do not see the point in continuing this discussion if this is the case.
>
> Thank you for your time and efforts.
> Those threads are voluntary, anyone is free to leave.
>
> >
> > > 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++?
> >
>
>
>
> > What I am proposing to change is based on fundamentals of C++.
> > I guess fundamentals are not ganna be deprecated!
> > Fundamentals are C++ version free.
> >
>
> This is nothing based on "fundamentals of C++", you break many of them.
> Same like with reflection, you misunderstand many of them.
>
> Beside any you do not understand again my point, you need
> change version you use to have "your feature" and it will be future
> version that will have reflection, this mean you can now
> change the version you use to one that has reflections.
> This means your change is pointless if refkection can easily
> do the same without breaking all C++ fundamentals.
>
> Sounds logic,
> Let keeps all this on the shelf until, the reflection change matures enough.
>

As I show here, it is near mature enough for many use cases.


> >
> > > 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`.
> >
>
>
> > I already sent an example of implementing the same, all the way in the beginning of this discussion. Check my conversation with Tiago.
> >
>
> No, you never give any real life example.
> I read all your examples, and they can be easily fixed
> by other features already existing or will soon exist in C++.
> Only this "slots" was close, but you did not prove that `std::any`e
> what types will be here anyway.
>
> Like this "vector" example, can be easy fix by:
>
> ```
> std::vector<void(*)()> vec;
> vec.push_back(&Handle<&f<int>>);
> vec.push_back(&Handle<&f<double>>);
> vec.push_back(&Handle<&f<long>>);
>
> for (auto& f : vec) f();
> ```
> No magic, all simple and work probably even in C++11.
>



> You omitted the main part of the snipet
> "the loop"
>

here:
```
for (auto& f : vec) f();
```

Is same as yours:

> for(const auto& f : vec)
> {
> cout << "function parameterized on t = " << /*some call to get the non-type template value*/ << endl;
>
> cout << "ret val =" << f(10) << endl;
> }


Simply the whole loop body is hidden in the `Handle` helper.
Show me real life problems that can't be handled like this.



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