Date: Wed, 21 Sep 2022 18:11:18 -0300
Don't get me wrong. I'm just suggesting a direction that would be less
surprising from what the author proposed. But I agree adding more implicit
transformations will be very hard to get accepted.
> Why does it need a second?
To address the issue the author mentioned. Now, if that's an issue worth
addressing is something you might want to take with the author.
> which could cause all sorts of problems if they get stored long-term?
Yes, if you store things long term, you must know they will be there long
term.
Do you have a suggestion that would address the issue mentioned by the
author in a better way?
On Wed, Sep 21, 2022 at 4:38 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Wed, Sep 21, 2022 at 2:13 PM Breno Guimarães via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > 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.
>
> C++ is a language that has a *lot* of internal, hidden code
> transformations in it. `operator->` already has a built-in one. Why
> does it need a second? And why should this one start implicitly
> generating lambda functions, which could cause all sorts of problems
> if they get stored long-term?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
surprising from what the author proposed. But I agree adding more implicit
transformations will be very hard to get accepted.
> Why does it need a second?
To address the issue the author mentioned. Now, if that's an issue worth
addressing is something you might want to take with the author.
> which could cause all sorts of problems if they get stored long-term?
Yes, if you store things long term, you must know they will be there long
term.
Do you have a suggestion that would address the issue mentioned by the
author in a better way?
On Wed, Sep 21, 2022 at 4:38 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Wed, Sep 21, 2022 at 2:13 PM Breno Guimarães via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > 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.
>
> C++ is a language that has a *lot* of internal, hidden code
> transformations in it. `operator->` already has a built-in one. Why
> does it need a second? And why should this one start implicitly
> generating lambda functions, which could cause all sorts of problems
> if they get stored long-term?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2022-09-21 21:11:29