sob., 11 lis 2023 o 14:51 Nikl Kelbon <kelbonage_at_[hidden]> napisał(a):
>
> 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.
> 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
>

Yes, some proposals can be rejected but others can be accepted but in
different forms.
But you need to consider it anyway and show that the thing you propose
is better than that.
Because if not better then why would the committee accept yours when
rejected "better"?

Another thing "simplify", you need to show this too in your paper, aka
tony tables and need to use concrie real life examples.
Besides, committee try to move away from macros as in some contexts
make code a lot harder to analyze.
Could this new functionality make macros too complex to handle? As it
will be fully Turing complete?
Sometimes current limitations are beneficial as it forces people to
rethink usage of it.

> сб, 11 нояб. 2023 г., 14:34 Marcin Jaczewski <marcinjaczewski86_at_[hidden]>:
>>
>> sob., 11 lis 2023 o 13:06 Nikl Kelbon <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]>:
>> >>
>> >> pt., 10 lis 2023 o 13:42 Nikl Kelbon via Std-Proposals
>> >> <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
>> >> >
>> >> >
>> >>
>> >> 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]>:
>> >> >>
>> >> >> 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]
>> >> >> 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