cppfront

cppfront copied to clipboard

On slide 74 in https://github.com/CppCon/CppCon2022/blob/main/Presentations/CppCon-2022-Sutter.pdf we have the example of initialization safety by naming the return values already in the definition

f:() -> (i: int, s: std::string) = {
  i = 1;
  s = "x";

  return;
}

We basically know this function returns i and s - and we guarantee initialization in the code with Cpp2 anyway.

Can't we just omit the empty return; then? What is the value of having to write return?

On slide 74 in https://github.com/CppCon/CppCon2022/blob/main/Presentations/CppCon-2022-Sutter.pdf we have the example of initialization safety by naming the return values already in the definition

f:() -> (i: int, s: std::string) = {
  i = 1;
  s = "x";

  return;
}

We basically know this function returns i and s - and we guarantee initialization in the code with Cpp2 anyway.

Can't we just omit the empty return; then? What is the value of having to write return?

I watched the Herb's presentation today, and just at this point I was thinking the same. Why is the real semantic value of having a return statement there? The unique reasonable explanation it to make explicit the fact that the function is a non void one, but, explicitly indicating the out parameters should be enought to disable the argument of "the return type is there to make explicit that the function returns a value`.

I must admit that I would love that the cpp2 project keeps going forward, and omit the old return would be one of that nice features that someone could expect about it.

explicitly indicating the out parameters should be enought to disable the argument of "the return type is there to make explicit that the function returns a value`.

out parameters and the return type are orthogonal. This issue is about anonymous return types.

The charitable interpretation of @Pyzyryab 's sentence is that he meant "explicitly indicating the return values (i:int, s: std::string) should be enough to disable the argument" :slightly_smiling_face:

@jcanizales that's a better interpretation that my explanation, thanks for it 👍

Even tho, mixing the best of both worlds, ommiting the return statement could be an optional syntax, for example, as Rust does.

Last sentence? No need to indicate return. cpp2, all paths safetly initializes the variables on out? No need to explicitly code a return keywork.

I am just trying to brainstorming about the optional return clause (for example?) concept.

I agree that the return; should be implicit. Added to the near-term to-do list! (roughly: look at over the holidays)

@ssproessig Done, thanks again.

FWIW, resolving this issue with this commit is a tiny milestone... it's the first commit in cppfront that generates new code (tokens and grammar). The facility to add tokens was on my list, because I also want it when coalescing two consecutive > into >> where the >> operator makes sense grammatically. (That's the opposite direction today's C++ does it, which is to break apart a single >> token into two > tokens contextually. I conjecture that combining them is easier, at least in the context of this compiler.) Then eventually I aim to let the programmer control generated code programmatically...

I agree that the return; should be implicit. Added to the near-term to-do list! (roughly: look at over the holidays)

Programmer holidays are just a mith! I am glad to see how Cpp2 keeps moving forward, and taking decisions that makes CPP looks freesher and nicer :)