Wiadomość napisana przez Sebastian Wittmeier via Std-Proposals <std-proposals@lists.isocpp.org> w dniu 19 mar 2025, o godz. 09:26:
AW: [std-proposals] Proposal: Making The auto Keyword Optional in Trailing Return Types It would, but with its own cost.
All current programs using fn as an identifier would malfunction.
There are far less common and longer potential keywords, which have been rejected for that reason.
-----Ursprüngliche Nachricht-----
Von: Filip <fph2137@gmail.com>
Gesendet: Mi 19.03.2025 09:22
Betreff: Re: [std-proposals] Proposal: Making The auto Keyword Optional in Trailing Return Types
An: std-proposals@lists.isocpp.org;
CC: Sebastian Wittmeier <wittmeier@projectalpha.org>; std-proposals@lists.isocpp.org;
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, FilipWiadomość napisana przez Sebastian Wittmeier via Std-Proposals <std-proposals@lists.isocpp.org> 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@lists.isocpp.org>
Gesendet: Mi 19.03.2025 02:57
Betreff: [std-proposals] Proposal: Making The auto Keyword Optional in Trailing Return Types
An: std-proposals@lists.isocpp.org;
CC: Fady al Dhaim <fadyaldhaim@gmail.com>;
Hello,
I’d like to propose a small but meaningful change to C++: making
autooptional in trailing return types.1. MotivationCurrently,
autois required in functions that use trailing return types:auto func() -> int; // RequiredHowever, this requirement is redundant and misleading because:
- The return type is explicitly specified (
int), soautoadds no value.autoimplies 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;withoutautomakes 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 CodeThis proposal is backward-compatible because:
autois already optional in normal return types:int func();This change is purely syntactic—it does not affect semantics.
Existing code using
autoremains fully valid.
auto func() -> int; // Remains valid
auto func() -> decltype(some_expression); // Also validThus, this proposal only removes an unnecessary restriction without introducing breaking changes.
3. Proposed ChangeModify the C++ grammar so that functions using trailing return types no longer require
auto.
This would allow:Current (C++ Standard Today)auto func() -> int; // RequiredProposed (New Syntax Allowance)func() -> int; // AllowedThis makes the syntax more consistent with regular function declarations.
4. Next StepsWould 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@lists.isocpp.org https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals--
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals