[BUG] forward return passing style produces bad cpp1 return type

[filipsajdak]

In the current implementation of cppfront, we can use a forward return passing style to return a reference from a function or use decltype(auto) to return an exact cv-qualified type.

Unfortunately, in some cases, it produces the wrong cpp1 code. E.g., in the following code:

fun4: (i : int) -> forward int = {
    return i;
}

fun4_in: (in i : int) -> forward int = {
    return i;
}

fun4_copy: (copy i : int) -> forward int = {
    return i;
}

fun4_move: (move i : int) -> forward int = {
    return i;
}

fun4_forward: (forward i : int) -> forward int = {
    return i;
}

Generates (skipping boilerplate):

[[nodiscard]] auto fun4(cpp2::in<int> i) -> int&{ // should be `const int&`
    return i; 
}

[[nodiscard]] auto fun4_in(cpp2::in<int> i) -> int&{ // should be `const int&`
    return i; 
}

[[nodiscard]] auto fun4_copy(int i) -> int&{  // non-const reference bind to temporary (maybe decltype(auto)?)
    return std::move(i); 
}

[[nodiscard]] auto fun4_move(int&& i) -> int&{  // non-const reference bind to temporary (maybe decltype(auto)?)
    return std::move(i); 
}

[[nodiscard]] auto fun4_forward(auto&& i) -> int& // should be decltype(auto) to forward type
requires std::is_same_v<CPP2_TYPEOF(i), int>
#line 18 "tests/bug_forward_return.cpp2"
{   return CPP2_FORWARD(i); 
}

[filipsajdak]

The issue found during discussion here: #247

[AbhinavK00]

This is offtopic, but copy passing convention seems... out of place. It does not convey intent like the other 5 conventions do and I think copy should be an annotation at call site rather than in the function signature. It should be made so that user calls method/function if he wants to pass the copy of an object to function. Something like,
func(v.copy());
and then the function can take the rvalue created as a move parameter.
Also, copy was not in the parameter passing paper, or was it?

[leejy12]

[[nodiscard]] auto fun4(cpp2::in<int> i) -> int&{ // should be `const int&`
    return i; 
}

[[nodiscard]] auto fun4_in(cpp2::in<int> i) -> int&{ // should be `const int&`
    return i; 
}

Are these functions intentionally returning references to local variables? Shouldn't they just be int because int is a "trivial" type?
Or maybe forward returning a local variable is ill-formed by nature and cppfront should just reject this kind of function. Can someone clarify this?

[filipsajdak]

@AbhinavK00, there are other issues regarding passing style (see: #231 (comment))

@hsutter mentioned the solution here: #198 (comment)

I'm currently supporting out, move, and forward arguments only. I'm thinking about copy or inout arguments in the future, but I don't plan to implement them now because I'm still thinking them through, and they probably require more work.

If I understand correctly, the idea is to emphasize intention on the call side by adding a passing style keyword:

// what is supported at the moment
fun(out x);     // x will be initialized (modified before use) in the fun
fun(move x);    // x moved to fun
fun(forward x); // x forward to fun

// what is planned
fun(copy x);    // x copied to fun
fun(inout x);   // x passed as inout parameter and cannot be rvalue

[AbhinavK00]

@filipsajdak I see, what I was saying is that I don't think there is a need for a copy passing convention, we already have five. We can always have user pass a copy by calling a method/function and take it in as a move parameter.
As for the annotations on callsite, there was this post on reddit which proposed the following

func(a)  //no annotation for in parameter 
func (b+)  //annotate with + to mark mutation, this encompasses both out and inout parameters 
func(c-)  //annotate with - to mark release, this encompasses both move and forward

You should check out full post for more info:
https://www.reddit.com/r/cppfront/comments/yt4cye/cppfront_callsite_parameter_specifiers/

[filipsajdak]

Are these functions intentionally returning references to local variables?

@leejy12 I missed your comment. Currently, the cppfront is returning a reference to temporary, which is an error (it will not compile on the cpp1 compiler).

Returning const ref was my proposal, but of course, it is my mistake as it still is a reference to temporary - it will compile on the cpp1 side but with warnings. It should be just a copy for these cases.

We can do the proper thing for generic function as the following:

fun: (i : int) -> forward _ = {
    return i;
}

It will generate:

[[nodiscard]] auto fun(cpp2::in<int> i) -> decltype(auto){
    return i; 
}

And the return type will be deduced correctly. There is an issue when we want to specify the forward return type, e.g. int. A similar issue is on the argument side when you want to forward an argument of a specific type. There is a solution by having a template that limits the type with a requires clause:

fun3_forward: (forward i : int) -> forward _ = {
    return i;
}

Generates:

[[nodiscard]] auto fun3_forward(auto&& i) -> decltype(auto) // template or auto is needed to allow perfect forwarding
  requires std::is_same_v<CPP2_TYPEOF(i), int>              // requires limits its match to only int
{   
  return CPP2_FORWARD(i);
}

[hsutter]

Thanks. forward return of a local (including parameter) isn't intended, and I should issue a diagnostic for these examples.

The purpose of forward return is to let the caller use the result to modify some data that is owned by the function but outlives it, such as /*vector or basic_string*/<T>::operator[] /*const/non-const*/ which would return forward /*const/non-const*/ T.

[filipsajdak]

@hsutter Take a look at the rest test cases I have made - maybe it will bring you more cases.

fun1: (i) -> forward _ = {
    return i;
}

fun2: (i : _) -> forward _ = {
    return i;
}

fun3: (i : int) -> forward _ = {
    return i;
}

fun4: (i : int) -> forward int = {
    return i;
}

fun1_in: (in i) -> forward _ = {
    return i;
}

fun2_in: (in i : _) -> forward _ = {
    return i;
}

fun3_in: (in i : int) -> forward _ = {
    return i;
}

fun4_in: (in i : int) -> forward int = {
    return i;
}

fun1_inout: (inout i) -> forward _ = {
    return i;
}

fun2_inout: (inout i : _) -> forward _ = {
    return i;
}

fun3_inout: (inout i : int) -> forward _ = {
    return i;
}

fun4_inout: (inout i : int) -> forward int = {
    return i;
}

fun1_copy: (copy i) -> forward _ = {
    return i;
}

fun2_copy: (copy i : _) -> forward _ = {
    return i;
}

fun3_copy: (copy i : int) -> forward _ = {
    return i;
}

fun4_copy: (copy i : int) -> forward int = {
    return i;
}

fun1_move: (move i) -> forward _ = {
    return i;
}

fun2_move: (move i : _) -> forward _ = {
    return i;
}

fun3_move: (move i : int) -> forward _ = {
    return i;
}

fun4_move: (move i : int) -> forward int = {
    return i;
}

fun1_forward: (forward i) -> forward _ = {
    return i;
}

fun2_forward: (forward i : _) -> forward _ = {
    return i;
}

fun3_forward: (forward i : int) -> forward _ = {
    return i;
}

fun4_forward: (forward i : int) -> forward int = {
    return i;
}

// fun1_out: (out i) -> forward _ = { // error: (temporary alpha limitation) an 'out' parameter cannot be a deduced type (at ')')
//     return i;
// }

// fun2_out: (out i : _) -> forward _ = { // error: (temporary alpha limitation) an 'out' parameter cannot be a deduced type (at ')')
//     return i;
// }

fun3_out: (out i : int) -> forward _ = {
    i = 42;
    return i;
}

fun4_out: (out i : int) -> forward int = {
    return fun4_out_int(out i);
}

fun4_out_int: (out i : int) -> forward int = { 
    i = 42;
    return i;
}

Generates:

[[nodiscard]] auto fun1(auto const& i) -> decltype(auto){
    return i; 
}

[[nodiscard]] auto fun2(auto const& i) -> decltype(auto){
    return i; 
}

[[nodiscard]] auto fun3(cpp2::in<int> i) -> decltype(auto){
    return i; 
}

[[nodiscard]] auto fun4(cpp2::in<int> i) -> int&{
    return i; 
}

[[nodiscard]] auto fun1_in(auto const& i) -> decltype(auto){
    return i; 
}

[[nodiscard]] auto fun2_in(auto const& i) -> decltype(auto){
    return i; 
}

[[nodiscard]] auto fun3_in(cpp2::in<int> i) -> decltype(auto){
    return i; 
}

[[nodiscard]] auto fun4_in(cpp2::in<int> i) -> int&{
    return i; 
}

[[nodiscard]] auto fun1_inout(auto& i) -> decltype(auto){
    return i; 
}

[[nodiscard]] auto fun2_inout(auto& i) -> decltype(auto){
    return i; 
}

[[nodiscard]] auto fun3_inout(int& i) -> decltype(auto){
    return i; 
}

[[nodiscard]] auto fun4_inout(int& i) -> int&{
    return i; 
}

[[nodiscard]] auto fun1_copy(auto i) -> decltype(auto){
    return std::move(i); 
}

[[nodiscard]] auto fun2_copy(auto i) -> decltype(auto){
    return std::move(i); 
}

[[nodiscard]] auto fun3_copy(int i) -> decltype(auto){
    return std::move(i); 
}

[[nodiscard]] auto fun4_copy(int i) -> int&{
    return std::move(i); 
}

[[nodiscard]] auto fun1_move(auto&& i) -> decltype(auto){
    return std::move(i); 
}

[[nodiscard]] auto fun2_move(auto&& i) -> decltype(auto){
    return std::move(i); 
}

[[nodiscard]] auto fun3_move(int&& i) -> decltype(auto){
    return std::move(i); 
}

[[nodiscard]] auto fun4_move(int&& i) -> int&{
    return std::move(i); 
}

[[nodiscard]] auto fun1_forward(auto&& i) -> decltype(auto){
    return CPP2_FORWARD(i); 
}

[[nodiscard]] auto fun2_forward(auto&& i) -> decltype(auto){
    return CPP2_FORWARD(i); 
}

[[nodiscard]] auto fun3_forward(auto&& i) -> decltype(auto)
requires std::is_same_v<CPP2_TYPEOF(i), int>
#line 90 "tests/bug_forward_return_type.cpp2"
{   return CPP2_FORWARD(i); 
}

[[nodiscard]] auto fun4_forward(auto&& i) -> int&
requires std::is_same_v<CPP2_TYPEOF(i), int>
#line 94 "tests/bug_forward_return_type.cpp2"
{   return CPP2_FORWARD(i); 
}

// fun1_out: (out i) -> forward _ = { // error: (temporary alpha limitation) an 'out' parameter cannot be a deduced type (at ')')
//     return i;
// }

// fun2_out: (out i : _) -> forward _ = { // error: (temporary alpha limitation) an 'out' parameter cannot be a deduced type (at ')')
//     return i;
// }

[[nodiscard]] auto fun3_out(cpp2::out<int> i) -> decltype(auto){
    i.construct(42);
    return i.value(); 
}

[[nodiscard]] auto fun4_out(cpp2::out<int> i) -> int&{
    return fun4_out_int(&   i); 
}

[[nodiscard]] auto fun4_out_int(cpp2::out<int> i) -> int&{
    i.construct(42);
    return i.value(); 
}

[leejy12]

Thanks. forward return of a local (including parameter) isn't intended, and I should issue a diagnostic for these examples.

Thanks for the answer. in, out, inout, move parameters can't be forward returned, but does it make sense to forward return forward parameters @hsutter?

The purpose of forward return is to let the caller use the result to modify some data that is owned by the function but outlives it, such as /vector or basic_string/::operator[] /const/non-const/ which would return forward /const/non-const/ T.

Cool. A cpp2 implementation could probably look something like this:

export template <typename T>
vector: class = {
private:
    data: *T;
	
public:
    operator[]: (pos: size_type) -> forward T = {
        return (data + pos)*;
    }

    operator[]: const (pos: size_type) -> forward const T = {
        return (data + pos)*;
    }
}

which will transpile to

export template <typename T>
class vector {
private:
    T* data;
	
public:
    T& operator[](size_type pos) {
        return (data + pos)*;
    }

    const T& operator[](size_type pos) const {
        return (data + pos)*;
    }
};

[hsutter]

Quick ack, since this was in my inbox this morning and I have a minute over morning coffee jot down notes for myself:

in, out, inout, move parameters can't be forward returned,

Briefly: in and move don't seem natural. But inout accepts only initialized lvalues, so forward-returning seems natural. And out similarly is guaranteed to be an initialized lvalue by the time you return.

does it make sense to forward return forward parameters

I think so. Examples of its usefulness today would be all functions that take a forwarding reference parameter and then return it with a decltype(auto) return type.

A cpp2 implementation could probably look something like this:

Pretty close, the syntax I'm contemplating is more like this which avoids special class/member grammar (quick notes: data members private by default and functions public by default, and explicit this which like all parameters is in by default which implies const, and defaults to the current type's name so there's no need to write the redundant : vector on the parameter type, and since they're single-return bodies we can use the existing short syntax for that):

vector: <T: type> class = {
    data: *T;
    size: size_type;
    // ...
    operator[]: (inout this, pos: size_type) -> forward T = std::span(data,size)[pos];
    operator[]: (this, pos: size_type) -> forward const T = std::span(data,size)[pos];
}

... something like that.

which will transpile to

Pretty much, but also with automatic bounds checking by default so you'll see the body emitted as { return cpp2::assert_in_bounds(std::span(data, size), pos); }, unless you disable bounds check injection with -s-.

[filipsajdak]

@hsutter What about the following code

print: (inout o : std::ostream, x : sometype) -> forward std::ostream = {
    return o << "# (x.name)$\n";
}

The intention is to return a reference to allow chaining:

o.print(x1).print(x2).print(x3);

In the current cppfront implementation, the code mentioned generates the following cpp1 code:

[[nodiscard]] auto print(std::ostream& o, cpp2::in<sometype> x) -> std::ostream&{
    return o << "# " + cpp2::to_string(x.name) + "\n"; 
}

forward return of a local (including parameter) isn't intended, and I should issue a diagnostic for these examples.

The purpose of forward return is to let the caller use the result to modify some data that is owned by the function but outlives it, such as /vector or basic_string/::operator[] /const/non-const/ which would return forward /const/non-const/ T.

Does it mean that my code is illegal? Maybe there is other way to achieve that?

[hsutter]

@filipsajdak, yes this is the kind of case I meant with the later addition that "inout accepts only initialized lvalues, so forward-returning seems natural. And out similarly is guaranteed to be an initialized lvalue by the time you return." I think that's sensible as you wrote it, and translates to the expected Cpp1 code. It's in and move that don't seem reasonable to forward-return.