*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*