Date: Tue, 18 Mar 2025 21:06:16 -0600
Hi,
This is a thoughtful proposal but I don't think it would work for C++.
My main concern is that this could make parsing even more difficult, and
it's already quite difficult. It seems it could add another place where
potentially arbitrary lookahead is required.
Secondly, visually, `foo() -> T { ... }` looks a bit weird to me. I'd love
a `fn foo() -> T { ... }`, but that's probably a tall order. So reusing
`auto` it is.
Cheers,
Jeremy
On Tue, Mar 18, 2025 at 7:56 PM Fady al Dhaim via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> *Hello,*
>
> I’d like to propose a small but meaningful change to C++: making auto
> optional in trailing return types.
> *1. Motivation*
>
> Currently, auto is required in functions that use trailing return types:
>
> auto func() -> int; // Required
>
> However, this requirement is *redundant and misleading* because:
>
> - The return type is *explicitly specified* (int), so auto adds no
> value.
> - auto implies type deduction, but *no deduction is happening* here.
>
> A more natural syntax would allow:
>
> func() -> int; // More intuitive Right?
>
> Not only does this improve *readability and consistency* with standard
> function declarations, but it also aligns well with *Software Engineering
> Structural Diagrams*, such as *UML Class Diagrams* and *Object Diagrams*.
>
> In UML Class Diagrams, method return types are typically represented *after
> the function name*, similar to how trailing return types work in C++.
> Allowing func() -> int; without auto makes the C++ syntax *closer to UML
> representations*, enhancing *clarity and traceability* between a codebase
> and its corresponding UML models.
> ------------------------------
> *2. Why This Won’t Break Existing Code*
>
> This proposal is *backward-compatible* because:
>
> -
>
> auto is *already optional* in normal return types:
>
> int func();
>
> -
>
> This change is *purely syntactic*—it does not affect semantics.
> -
>
> Existing code using auto remains *fully valid*.
> auto func() -> int; // Remains valid
> auto func() -> decltype(some_expression); // Also valid
>
> Thus, this proposal only *removes an unnecessary restriction* without
> introducing breaking changes.
> ------------------------------
> *3. Proposed Change*
>
> Modify the *C++ grammar* so that functions using *trailing return types*
> no longer require auto.
> This would allow:
> *Current (C++ Standard Today)*
>
> auto func() -> int; // Required
>
> *Proposed (New Syntax Allowance)*
>
> func() -> int; // Allowed
>
> This makes the syntax more *consistent* with regular function
> declarations.
> ------------------------------
> *4. Next Steps*
>
> Would this be a reasonable proposal for a future C++ standard update?
> I’d love to hear your thoughts and suggestions on how this could be
> refined further.
>
> Best regards,
> *Fady al Dhaim*
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
This is a thoughtful proposal but I don't think it would work for C++.
My main concern is that this could make parsing even more difficult, and
it's already quite difficult. It seems it could add another place where
potentially arbitrary lookahead is required.
Secondly, visually, `foo() -> T { ... }` looks a bit weird to me. I'd love
a `fn foo() -> T { ... }`, but that's probably a tall order. So reusing
`auto` it is.
Cheers,
Jeremy
On Tue, Mar 18, 2025 at 7:56 PM Fady al Dhaim via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> *Hello,*
>
> I’d like to propose a small but meaningful change to C++: making auto
> optional in trailing return types.
> *1. Motivation*
>
> Currently, auto is required in functions that use trailing return types:
>
> auto func() -> int; // Required
>
> However, this requirement is *redundant and misleading* because:
>
> - The return type is *explicitly specified* (int), so auto adds no
> value.
> - auto implies type deduction, but *no deduction is happening* here.
>
> A more natural syntax would allow:
>
> func() -> int; // More intuitive Right?
>
> Not only does this improve *readability and consistency* with standard
> function declarations, but it also aligns well with *Software Engineering
> Structural Diagrams*, such as *UML Class Diagrams* and *Object Diagrams*.
>
> In UML Class Diagrams, method return types are typically represented *after
> the function name*, similar to how trailing return types work in C++.
> Allowing func() -> int; without auto makes the C++ syntax *closer to UML
> representations*, enhancing *clarity and traceability* between a codebase
> and its corresponding UML models.
> ------------------------------
> *2. Why This Won’t Break Existing Code*
>
> This proposal is *backward-compatible* because:
>
> -
>
> auto is *already optional* in normal return types:
>
> int func();
>
> -
>
> This change is *purely syntactic*—it does not affect semantics.
> -
>
> Existing code using auto remains *fully valid*.
> auto func() -> int; // Remains valid
> auto func() -> decltype(some_expression); // Also valid
>
> Thus, this proposal only *removes an unnecessary restriction* without
> introducing breaking changes.
> ------------------------------
> *3. Proposed Change*
>
> Modify the *C++ grammar* so that functions using *trailing return types*
> no longer require auto.
> This would allow:
> *Current (C++ Standard Today)*
>
> auto func() -> int; // Required
>
> *Proposed (New Syntax Allowance)*
>
> func() -> int; // Allowed
>
> This makes the syntax more *consistent* with regular function
> declarations.
> ------------------------------
> *4. Next Steps*
>
> Would this be a reasonable proposal for a future C++ standard update?
> I’d love to hear your thoughts and suggestions on how this could be
> refined further.
>
> Best regards,
> *Fady al Dhaim*
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2025-03-19 03:06:28