Hi,

My first feeling is this is too drastic of a change in terms of language
ergonomics. Perhaps, if you word it a bit differently it would fit a bit
better with the rest of the language.
For example, instead of using the "inline" keyword as a placeholder to
"whatever is passed after ->", you could make the syntactic sugar to just
generate a lambda.

Such that:

v->Init();

would be transformed by the compiler into

v.operator->( [&] (auto& arg) { arg.Init(); } );

By doing so, all you need is the ability to pass more arguments to the
operator-> (today it's forbidden).
See how that would work for variant: https://godbolt.org/z/xxKnE44dr

That might still be a big stretch, but it seems to me it would be more
reasonable.

Best Regards,
Breno G.






On Wed, Sep 21, 2022 at 8:49 AM Михаил Найденов via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hello, again I want to point to pattern matching.
>
> I mean, we are 2/3 there.
> 1) we have the desire to have PM as expression, so that we can use it on
> the RHS of assignment
> 2) we have Concepts, so that we can select the alternative, based on its
> structure
>
> Last point is to have an attractive syntax, so that people will not
> require another language feature.
>
>
> On Wed, Sep 21, 2022 at 12:59 PM Frederick Virchanza Gotham via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>> My draft paper can be downloaded from here:
>>
>> http://www.virjacode.com/proposal_operator_inline.pdf
>>
>> Of course it needs loads more work.
>> --
>> 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
>