> Just a thought but wouldn’t introducing keyword ‘fn’ Simplify compilation?

It would probably have to be a contextual keyword. I’m not sure it it would
end up simplifying thing here.

Cheers,
Jeremy

On Wed, Mar 19, 2025 at 02:21 Filip via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Just a thought but wouldn’t introducing keyword ‘fn’
> Simplify compilation?
> It would be easier for the compiler to know if what is being written is
> specifically a function or a variable.
>
> Cheers, Filip
>
> Wiadomość napisana przez Sebastian Wittmeier via Std-Proposals <
> std-proposals_at_[hidden]> w dniu 19 mar 2025, o godz. 07:02:
>
> 
>
> See
>
>
> https://www.reddit.com/r/cpp/comments/cn863t/why_is_auto_required_when_using_a_trailing_return/?rdt=44901
>
> with
>
> https://godbolt.org/z/2jXUG9
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Fady al Dhaim via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Mi 19.03.2025 02:57
> *Betreff:* [std-proposals] Proposal: Making The auto Keyword Optional in
> Trailing Return Types
> *An:* std-proposals_at_[hidden];
> *CC:* Fady al Dhaim <fadyaldhaim_at_[hidden]>;
>
> *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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>