śr., 19 mar 2025 o 10:22 Filip via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> Huge resources to change the name from fn to fun or func or even just Fn?
> Maybe it could be rolled out in 2 iterations, firstly restrict the use of keyword and warn the user that in the next standard it will be a keyword introducing a function and then just change it.
>

Yes, consider the same header files that are used by two projects, and
only one project moves to the new standard.
Now you need to add `#ifdef` to handle both, you make this wrongly and
you break third unrelated projects that use hacked version of Clang.

Now multiple hundred headers by a hundred projects and you will have
10+ years Python2-3 transition where any file could be "easy" upgrade
from 2 to 3.

> To make it more appealing for change maybe this style could also resolve the issue of declaring a function? Is it impossible right now for the compiler to assume that the function of a given signature should exist by the end of compilation and just wait for it?
>
> I’m not advocating complete change and departure from c style functions, but it could be a compiler flag or something that could warn us about the mixed used of different declarations styles.
>
> To be honest I think that there’s a lot of organizations that still use c++11 or 14. They don’t want to update it “because it works already”.
> But we can’t really measure that.
>
> Wiadomość napisana przez Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> w dniu 19 mar 2025, o godz. 09:58:
>
> 
>
> No, it is not easy.
>
> An important corner stone of C/C++ is compatibility.
>
>
>
> Changes of code or checks, even if it can be automatically done, cost huge resources. Many organizations would delay or stop to update to newer C++ revisions.
>
>
>
> There are companies with hundreds of millions of lines of code.
>
> Even with tooling support, your suggestion easily could cost a million or more for each of them.
>
>
>
> And this only, if you now support old and new syntax, which makes it even more difficult to compile.
>
>
>
> Allowing function definitions and declarations _only_ with fn keyword would be a dead-end and language split. 99.9% would not follow such a new standard. Some just for the reason because they know that this variant would have no future.
>
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Filip <fph2137_at_[hidden]>
> Gesendet: Mi 19.03.2025 09:37
> Betreff: Re: [std-proposals] Proposal: Making The auto Keyword Optional in Trailing Return Types
> An: std-proposals_at_[hidden];
> CC: Sebastian Wittmeier <wittmeier_at_[hidden]>; std-proposals_at_[hidden];
> Changing the name of that identifier is easy so maybe it’s possible to warn programmers about it and just introduce it if it’s going to help us.
>
> A bit of uncomfortable phase, sure, but maybe it’s better that way for everyone.
>
> Cheers, Filip
>
> Wiadomość napisana przez Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> w dniu 19 mar 2025, o godz. 09:26:
>
> 
>
> 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_at_[hidden]>
> Gesendet: Mi 19.03.2025 09:22
> Betreff: Re: [std-proposals] Proposal: Making The auto Keyword Optional in Trailing Return Types
> An: std-proposals_at_[hidden];
> CC: Sebastian Wittmeier <wittmeier_at_[hidden]>; std-proposals_at_[hidden];
> 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
>
> --
> 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