On 11/11/2023 14.51, Nikl Kelbon via Std-Proposals wrote:
> I saw all proposals about reflection, auto [...args] etc, but some of them will not be accepted to standard, others, like reflection, is too big and complex to support them.

What do you mean by "is too big and complex to support them"?

Are you speaking as an implementer stating that you'll refrain from
implementing a hypothetical future reflection facility (and thus
rendering your implementation non-conforming)?

If not, what is the basis for this claim?

I do note that P2996 (Reflection for C++26) has just progressed to
the next review step:

https://github.com/cplusplus/papers/issues/1668

Jens



> Im not fun of doubling c++ standard just for writing java like interfaces in 10 rows of code, but that's is all reflection can offer me
> And I see no reason to forbid recursive macro, when it is easy to implement and it's in fact can simplify huge amount of code, code which is already here.
> You can create a huge and complex reflection, but it will never be possible to do what simple recursive macro can without loss expressiveness. All examples of reflection I saw were serialization, bitflags enum and useless java interfaces.
> So, I just decide to improve existing tool and do not create new, because language already too complex
>
> сб, 11 нояб. 2023 г., 14:34 Marcin Jaczewski <marcinjaczewski86_at_[hidden] <mailto:marcinjaczewski86_at_[hidden]>>:
>
> sob., 11 lis 2023 o 13:06 Nikl Kelbon <kelbonage_at_[hidden] <mailto:kelbonage_at_[hidden]>> napisał(a):
> >
> > > There was even
> >
> > 'was' =(
> > > real life examples/problems
> >
> > There are example from nlohmann json, magic enum, i use it for my de/serialization in personal project
> >
> > > the good old X Macro
> >
> > As you see no one uses this 'good old' technique, no nlohmann json, no boost preprocessor. Because this do not solve those problems
> >
>
> And maybe this is a problem? You did not analyze how each solution
> works and what drawbacks have.
> You should make "Tony tables" of each possible solution that show that
> your proposal is superior to old ones.
> And use some concrete examples from real life code to prove your point.
>
> Besides, some problems you presented could be solved by static
> reflection, and you need to consider this in your paper too.
>
>
> > сб, 11 нояб. 2023 г. в 01:00, Marcin Jaczewski <marcinjaczewski86_at_[hidden] <mailto:marcinjaczewski86_at_[hidden]>>:
> >>
> >> pt., 10 lis 2023 o 13:42 Nikl Kelbon via Std-Proposals
> >> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> napisał(a):
> >> >
> >> > Here is examples, recursion stops when `__VA_OPT__` will not expands (`__VA_ARGS__` empty), In case on infitine recursion there are impl-defined limit
> >> >
> >> > implementation and discurssion here:
> >> > https://github.com/llvm/llvm-project/pull/65851 <https://github.com/llvm/llvm-project/pull/65851>
> >> >
> >> >
> >>
> >> Could you provide more real life examples/problems where this could be useful?
> >> In your pdf the only example of this was `tie_aggregate` but
> >> this was more of a problem in C++ than
> >> something that should be fixed by macros.
> >> There was even a proposal that had a proper solution for this:
> >>
> >> ```
> >> auto [...pack] = aggregate;
> >> ```
> >>
> >> Another thing is how your proposal is better than the good old X Macro
> >> technique?
> >>
> >>
> >>
> >> > пт, 10 нояб. 2023 г. в 16:37, Andrey Semashev via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>:
> >> >>
> >> >> On 11/10/23 15:22, Nikl Kelbon via Std-Proposals wrote:
> >> >> > Hi all, I would like to propose a minor addition to the preprocessor,
> >> >> > that has the potencial to significantly simplify writing and reading
> >> >> > macros, give new features that were not there.
> >> >> >
> >> >> > I propose a special token '__THIS_MACRO__'(similar to '__VA_ARGS__' and
> >> >> > '__VA_OPT__' ), which will add the possibility to write recursive macros.
> >> >> >
> >> >> > Simple example:
> >> >> >
> >> >> > #define fold_right( op , head , ...) \
> >> >> > ( head __VA_OPT__ ( op __THIS_MACRO__(op, __VA_ARGS__ )))
> >> >> > /* expands to (1 + (2 + (3))) */
> >> >> > int i = fold_right(+ , 1 , 2 , 3 );
> >> >> >
> >> >> >
> >> >> > This can be used in many different scenarios,
> >> >> > * declaring enums with enum info(like names, count, etc)
> >> >> > * boost describe struct
> >> >> > * ... more examples in 'pdf' ...
> >> >>
> >> >> When does the recursion stop? IOW, what one is supposed to write in the
> >> >> macro definition to stop the recursion at a certain point?
> >> >>
> >> >> --
> >> >> Std-Proposals mailing list
> >> >> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> >> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
> >> >
> >> > --
> >> > Std-Proposals mailing list
> >> > Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> >> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>