return; in functions with explicit Void return type

[zygoloid]

We should consider one change relative to the C++ rules for return; / return expression;.

In C++ and in #415, either form can be used in a function with a Void return type. The proposed alternative rule is:

• If the function specifies a return type (eg, fn F() -> Int { or fn F() -> Void {), then every return statement must have an expression, and control reaching the end of the function is a bug (without meaning to specify here what the response to the bug is -- UB or a diagnostic or a trap or something).
• If the function does not specify a return type (eg, fn F() {), then every return statement (if any) must be of the form return;, and control reaching the end of the function implicitly returns.

This makes the handling of Void uniform, removing special cases, while still supporting both return; in the "functions that don't return a value" case and also return expression; in a generic context even when the return type ends up being Void.

[fowles]

Richard~ What about the current structure for must_tail which requires `return foo()` for void tail calls? Matt

…

On Tue, May 4, 2021, 4:39 PM Richard Smith ***@***.***> wrote: We should consider one change relative to the C++ rules for return; / return expression;. In C++ and in #415 <#415>, either form can be used in a function with a Void return type. The proposed alternative rule is: - If the function specifies a return type (eg, fn F() -> Int { or fn F() -> Void {), then every return statement must have an expression, and control reaching the end of the function is a bug (without meaning to specify here what the response to the bug is -- UB or a diagnostic or a trap or something). - If the function does not specify a return type (eg, fn F() {), then every return statement (if any) must be of the form return;, and control reaching the end of the function implicitly returns. This makes the handling of Void uniform, removing special cases, while still supporting both return; in the "functions that don't return a value" case and also return expression; in a generic context even when the return type ends up being Void. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#518>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAALOCTWC6Y2VJGWPQ2VW2TTMBLRFANCNFSM44DNEHPQ> .

[zygoloid]

What about the current structure for must_tail which requires return foo() for void tail calls?

If we were to exactly follow the design of the Clang attribute, this would mean that function that contain a guaranteed tail call would need to be written with an explicit return type -- fn FThatMakesATailCall() -> Void { -- instead of with an omitted return type. But I think there are lots of assumptions here, and we might end up with a completely different syntax for guaranteed tail calls in Carbon -- assuming we have them at all.

[chandlerc]

Agreed with the suggested direction. We might want to restrict further or tweak, but this is a good start.

and we might end up with a completely different syntax for guaranteed tail calls in Carbon -- assuming we have them at all

FWIW, I would like tail calls, but would specifically prefer a different syntax. Anyways, not something we need to stress about today.

[zygoloid]

Decision: Make the proposed change.