hsutter / cppfront

A personal experimental C++ Syntax 2 -> Syntax 1 compiler
Other
5.56k stars 249 forks source link

[SUGGESTION] Allow perfect return capturing `r: forward _ = func()` #1332

Open MaxSagebaum opened 3 weeks ago

MaxSagebaum commented 3 weeks ago

With decltype(auto) r = func(); the return from a function can be perfectly captured.

With the change in 0.8, we have now -> foward _ = {...} for perfect return type forwarding. We could enable the same for perfect capturing. E.g.:

  r: forward _ = func(x);
  use_r(r);

Edit1: As @JohelEGP mentioned forward r: _ = func(x); would be more consistent. __Edit1_end__

Why is this required? If use_r is declared as use_r: (inout r) = {...} then the direct return forwarding use_r(func(x)) is not always possible. If func(x) returns a value it can not be bound to a reference.

My use case: I kind of need this in the regular expression implementation. My matching context is always captured as an inout value. I do not want to have copies of this value. For the lookbehind implementation and nested versions of lookbehind and lookforward, I need to convert the context into itself or a reverse context. So one is a reference and one is a new object. For these cases I need decltype(auto) r = ....

I circumvented the issue currently by relaxing the inout ctx to forward ctx on the generated functions. But then I had to add a hack to prevent forwarding of ctx by adding a _ = ctx; at the end of the function.

I tried to find the location in cppfront where this is implemented, but could not find it. With a hint I would be filling to create a PR.

JohelEGP commented 3 weeks ago

FWIW, we already have that syntax you mentioned.

I just noticed that we also don't have decltype(auto) for variables. The best approximation are forward: _ parameters: https://cpp2.godbolt.org/z/MKsocP6bb.

-- https://github.com/hsutter/cppfront/pull/921#issuecomment-2391985086

So maybe rather than r: foward _ = func(x);, it should be forward r := func(x); for consistency.

MaxSagebaum commented 3 weeks ago

You mean v2 in your code example that is marked as does not work?

If so, that is what I am suggesting. But you are right forward r: _ = func(x); would be more consistent. I added this to the initial post. Thanks.